Modifying Option Byte Value from Program Running in SRAM and Loaded using dfu-util

mykepredko · ‎2025-04-07

I want to write a program for a fresh (first time power applied to it so there is nothing in Flash) STM32G0B1 that executes in RAM, resets the nBOOT_SEL bit in the Option Bytes (to allow DFU Mode to be invoked when Flash has been written).

The reason why I want to execute in RAM is to avoid having to run a program that is loaded in Flash (and resets nBOOT_SEL as discussed above) which is loaded into Flash that requires a power cycle to restart so that DFU Mode can be enabled in the MCU to load the actual product firmware.

This is being done in manufacturing test, so avoiding a power cycle (which takes about a minute due to other hardware in the application) would be of advantage.

Could anybody point me to:

A dfu-util statement that a bin file at a specific SRAM address and has execution continue from there
Pointers to how the application would be configured. What I have found so far are:
In my research, it seems like the USB as well as another interrupt needs to be disabled while running an application like this. Does anybody have any references which explains what is required?

I think the last two links for creating a program that runs in SRAM are probably closest to what I want to do but I'm hoping that there is a crisp explanation that I can follow.

For resetting the nBOOL_SEL bit, I'm going to use the following guide (with standard STM/HAL development tools/libraries):

https://community.st.com/t5/stm32-mcus/how-to-program-stm32-option-bytes-with-the-hal-api/ta-p/49660

Any comments or suggestions are most welcome!

myke

mykepredko · ‎2025-04-16

I wanted to follow up with this - I've got an application running that resets the nBOOT_SEL bit but now I need to get it running in SRAM after being loaded into the STM32G0B1RET6 MCU using DFU.

First I created a simple application to Flash an LED on the test board, I created a .bin version of it and loaded it using DFU:

As you can see in the screenshot above, the download takes place without issue.

The only problem I have is that the code won't start executing after I load it - I have tried adding the ":leave" modifier but no joy. If I reset the board, the code works fine with the LED flashing as expected.

---

For testing in SRAM, I fully erase the MCU to make sure I don't get any unexpected results from a previous Flash load.

I created a new project with the same main.c as the first case but with the following changes:

In "STM32G0B1RETX_FLASH.ld" and "STM32G0B1RETX_RAM.ld", I set the memory definition as:

MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20002000,   LENGTH = 144K
  FLASH  (rx)     : ORIGIN = 0x20000000,   LENGTH = 512K
}

Next, in system_stm32g0xx.c I uncommented the lines containing "#define USER_VECT_TAB_ADDRESS" and "#define VECT_TAB_SRAM" to change the Vector Table into SRAM rather than in Flash.
After building the application, I checked to see that the (fully erased) MCU was in DFU Mode and then attempted to download the application with the results (failing at the end):
I then attach S-Link, connect (without touching anything on the board including power or the USB cable) and look at the contents of SRAM and see:
This ain't great because when I look at the contents of the .bin file I see:

So, the immediate issues I see here are:

There is a problem with the SRAM download (see point 3. above stating that the "last page" isn't writeable).
The contents of SRAM aren't what I expect. I've never done this before so I don't know what to expect but I think it's reasonable to think that I should see the contents of the .bin file at some location.

So, any ideas?

@clkr , I've seen your post and, I'm not disabling the interrupts used by DFU - I think this explains why the Flashed version doesn't start (I've tried it with both with and without the ":leave" Modifier to the "-s" dfu-util option.

Thanx - I feel like it's something simple but I really can't figure out what I'm doing wrong.

myke