FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

STM32G option bytes modification fails in DFU mode

FValm.1
Associate III

‎2022-02-22 04:16 AM

I'm working with a host PC running a C++ Visual Studio project which is running some API calls to implement the DFU protocol. Those API are exposed by some DLL and LIB file available with STM32CubeProgrammer. The host PC is connected via a USB cable to a STM32G474 started in DFU mode (internal flash bootloader).

The PC and the STM32 are well connected because the first calls of the API which establish the connection and retrieve informations about the MCU (like the device ID, the name of the MCU and so on) work correctly.

The problem comes when I try to change the DBANK option in DFU mode using the API function sendOptionBytesCmd which is an API available to change some parameter of the option bytes. That function returns a CUBEPROGRAMMER_ERROR_READ_MEM error (after a 3-4 seconds of timeout). Indeed, after that error, if I explore the DBANK parameter in the option byte using STM32CubeProgrammer, I can see that the DBANK is changed. So the question is: why that API produce such an error? Anybody has faced the same problem? Did I miss some setting before the API call which is necessary to avoid that error (and the associated long timeout)?

Labels:
0 Kudos
1 REPLY 1
FValm.1
Associate III

‎2022-02-22 08:29 AM

Ok, perhaps I can answer to my problem. At least why the call to that API fails. Anyway I have to give you some additional information on how it is structured the program which runs in the MCU. The MCU initially starts in non DFU mode and exposes to the host PC a HID custom interface. Then it receives from host PC a specific command that produces a jump to the internal flash where bootloader is written. At this point the MCU can receive the DFU command from PC. The problem is that any reset to the MCU, in such configuration, makes it restarting from user flash. And that is what happens when in DFU I call that API. After modifying the DBANK option to 0 (single bank) the API function resets the MCU and since the program was originally flashed for dual bank configuration (it was originally flashed with STM32CubeIde) then the program cannot start again.

I know that someone could ask me why all this complications to program a flash in single bank. Well my purpose was to manage the programming of the flash by PC in every situation (brand new flash or flash containing a running program) using the system bootloader. At this point I can say my problem is perhaps a false problem.

  • If the flash has been never programmed (all 0xFF) the host PC must recognize that situation (and this will be accomplished by a HW timer that will set the MCU in DFU mode changing the BOOT 0 pin to a high state and resetting the MCU). The PC will recognize that situation because HID custom interface will be unavailable while DFU will be available at first connection. So it will change first the DBANK to 0 (single bank) and so it will program the flash in single bank
  • If the flash has been already programmed then it was programmed by the PC in single bank mode and it is not required to change DBANK to 0. PC will recognize that situation because the HID custome interface will be available at start of connection.
  • And if the flash is corrupted? Well in that case the HW timer should again set the MCU in DFU mode (pin BOOT0 high and reset to MCU). So also this case is similar to the first

Hoping these considerations can be useful for someone else...:smiling_face_with_smiling_eyes:

0 Kudos
Top