[feature] Option bytes on the STM32F767 ZIT6 Nucleo-144

[rutgerhendriks]

• Programmer/board type: Stlink/v2-onboard
• Programmer firmware version: ?
• Operating system: Linux
• Stlink tools version and/or git commit hash: 1.6.0-350-g3e49bec-dirty
• Stlink commandline tool name: st-flash
• Target chip (and optional board): STM32F767ZIT6 Nucleo-144

Commandline-Output:

Commandline:
st-flash --area=option read

Output:
Option bytes read is currently not supported for connected chip
could not read option bytes (-1)

Expected/description:

TL;DR
Reading or writing option bytes on the F76xxx is currently not supported. Adding support worked, but I have some confusion on how option bytes are handled.

For a project I need to change the boot_add option byte to a different value in order to boot the device from a different sector than the default value.
The thing is, the boot_add0 and boot_add1 option bytes are not written using the standard FLASH_OPTCR address, but with the FLASH_OPTCR1 address 4 bytes further

By adding functions for the F7 and FLASH_F7 defines (copy of F4 functions and defines) and adding the FLASH_F7_OPTCR1, I'm able to write the desired option byte boot_add0.

I'm willing to provide a pull request, but I'm not sure how to proceed at this moment, because it seems to me that option bytes in the project are a special beast. To support option bytes the option_base and option_size need to be added to chipid.c (in this case the base is 0x1FFF0000 and the size is 0x20) and checks are present for this, but the option bytes themselves are read and written using FLASH_Fx_OPTCR and therefor expect exactly one 32bit value. Perhaps the current behaviour is correct for some chips, but it is not for the F767.

I would propose to add the following to support the OPTCR1 boot_add0 and boot_add1 options:

• add --area=option_boot_add to write the value using FLASH_F7_OPTCR1

I would propose to change the following to make option bytes more clear/consistent:

• add --area=optcr to read/write the current option control register (part 0)
• add --area=optcr1 to read/write the current option control register part 1
• change --area=option to read the option_base iso the FLASH_xx_OPTCR

How do you guys feel about this? Will it work for other chips too?

[Nightwalker-87]

@rutgerhendriks: You can give it a try and see if everything works as intended.

[Nightwalker-87]

@rutgerhendriks : Any update on this?

[rutgerhendriks]

Well, I got it to work, so that's great. Now I need to get it cleaned up and make a PR that does only this..

[rutgerhendriks]

I created the PR #997. I see there are some conflicts now, how to proceed in resolving them?

[Nightwalker-87]

I think these conflicts appear more complex than they actually are.
There was some reorganisation of the source code recently to improve its appearance.
From the conflict resolve message I read that you still worked with the previous subfolder structure.
Have a look at the current directory structure in develop and introduce your changes based on this state so that respective files are recognised correctly by git.
Try to submit another commit to your PR and it should be resolvable. There is no need to open a new PR, I think.

[rutgerhendriks]

ok, I'll have a look

[Nightwalker-87]

I know there was a lot going on recently, but don't bother too much about it - take your time.
I'd propose to rename the files in the mentioned paths and subsequently merge-in develop.
You can then look at your specific changes again. It should work like this.
I can review afterwards to see if there are any unintended leftovers.