Is there an app note on the debugger interaction with the option bytes?

[Robert Ritchey]

I am trying to figure out how the debugger interacts with the option bytes, or seems to.

I am using the STM32G030C6 and have included programming the option bytes into the source code and linker file. This is in one of my source files:

const uint32_t __attribute__((section (".option_bytes")))
 OPTION_BYTES[10] __attribute__((used))
 = { 0xDFFE81AA, 0x20017E55,
 0xFFFFFFFF, 0x00000000,
 0x00FF0000, 0xFF00FFFF,
 0xFF00FF3F, 0x00FF00C0,
 0xFF00FF3F, 0x00FF00C0};

and these are in the linker file:

MEMORY
{
 RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 8K 
 FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 28K
 OPTION (r) : ORIGIN = 0x1FFF7800, LENGTH = 40
}
 
SECTIONS
{
...
 .option_bytes : 
 {
 . = ALIGN(8);
 KEEP(*(.option_bytes))
 . = ALIGN(8);
 } >OPTION

What I am finding is that when I run the debugger, the flash memory locations show the default values for the option bytes and the FLASH option register (FLASH_OPTR) also shows the defaults but the code acts erratically. I changed the defaults so the IWDG is set to hardware and reset should be generated for standby and stop modes.

But if I download this file with STM32CubeIDE and look at the flash memory locations for the option bytes, the values I set in my source code are there. The unit seems to run fine but I have only gotten into this today.

So, it seems the debugger is overriding the values I am setting in my source code but I am getting erratic behavior. As the question states, is there a app note that address this?

Thanks,

[Tesla DeLorean]

Perhaps writing them at every debug pass is not the way to do this?

Maybe have your app code check the current values against the desired values, and update IF required.

In the production programming you might want to ensure the processes is done once.

[Robert Ritchey]

Could you explain Why this would be an issue? I have the debugger do a bulk erase (monitor flash mass_erase) before each download so I would think the option bytes go back to default every time. Even so, what difference would writing these every debug cycle make?

[Tesla DeLorean]

If I understand the option-byte mechanics here, some are only pulled via a power-cycling of the device, this is usually not something the debugger is capable of pulling off. There's also the potential to set things that are incompatible with debugging.

I do however think that you need to separate the iterative/debug methodology from your production programming one. Too many moving parts. many where the implementation is opaque.

I think having all the options, otp or whatever in the production image is a good one.

Could be a GNU/GDB/OCD bug, hard to say. Not my tools

[TDK]

> debugger do a bulk erase (monitor flash mass_erase) before each download so I would think the option bytes go back to default every time

I doubt a mass erase touches the option bytes at all. Technically they are in flash memory, but not within the 0x08000000 region commonly referred to as flash. There are many things in there that wouldn't make sense to touch.

[Piranha]

Tesla's advice really is the best. Use FLASH_OPTR and other corresponding registers and make a code, which checks those at startup. If option bytes need modification, code reprograms those and performs the system reset. The system reset ensures, that, for example, a watchdog is started, when set to start by system.

[Fgedf.1]

Tesla's advice genuinely is the great. Use FLASH_OPTR and other corresponding registers and make a code, which assessments the ones at startup on getflink. If choice bytes want modification, code reprograms the ones and plays the gadget reset.

[Robert Ritchey]

I am pretty sure that using this method, someone can attach a debugger, breakpoint the reset vector and read the code out before the program is executed.