DFU programming error

[PKola.1]

If I use the DFU programming over USB with STM32CubeProgrammer, the error occurred and the device doesn't start properly, but if I download the same program with ST-LINK everything runs ok. The MCU is STM32 G473.

I can connect the MCU over the USB, and read memory. Also, the data download and the data verification are ok. The programming procedure fails after the RUNNING PROGRAM... an error occurred after sending a dfu end of download request.

After that, the device doesn't work properly and it is stuck, but if I reset it starts working normally except for the EEPROM emulation that fails to write to FLASH memory. I attached the log from CubeProgrammer.

 

[Tesla DeLorean]

>>but if I download the same program with ST-LINK everything runs ok

These are entire different and independent methods.

Check you have a crystal based clock

For issues with the EEPROM Emulation perhaps look more specifically at the FLASH registers any errors/status reported there. Perhaps write/read access limitations. Addresses and Sizes of sectors being utilized.

[PKola.1]

In the design is used the 24 MHz crystal. 

There are set three error flags in the FLASH register when writing after the firmware was flashed by the USB DFU. The PROGERR, PGAERR and PGSERR are set after calling FLASH_Program_DoubleWord by the EEPROM emulator driver.

If the firmware was downloaded with ST-LINK, there is no error when EEPROM is written.

[PKola.1]

My colleague find the solution to the first problem, why the program doesn't start after flashing by DFU. If the #define USER_VECT_TAB_ADDRESS is uncomment in the system_stm32g4xx.c file, the vector table address is set to 0x08000000UL. After that program runs fine.

The error occurred after sending a dfu end of download request. is not the problem because this text is shown also when others MCUs are flashed with DFU and work fine.

The only problem that persists is EEPROM write fail after programming MCU by DFU.

[PKola.1]

@heveskar​ 

We tried different methods of loading the binary from STM32CubeProgrammer. We used either System Bootloader (using USB) or directly via ST-Link.

Here are our results when the EEPROM emulation works and when there is error:

- When loading .bin file from USB bootloader or via ST-Link, EEPROM emulation does not work

- When loading .hex file from ST-Link, it works correctly

- When loading .hex file via USB bootloader, it does not work. However, after device reset, it starts working correctly.

- When loading .elf via ST-Link, it works

- When loading .elf via USB bootloader to an empty device, it does not work. However, when loaded to a device that is already loaded, it works correctly

To sum it up, using USB bootloader, only option working correctly is loading .elf to an already loaded device; .bin works after reset. Using ST-Link, everything except .bin works correctly.

For .bin loading, we set starting address of 0x8000000. User option bytes are all checked except BFB2 (however, turning this on does not change anything).

[PKola.1]

Another update:

If we remove the ROM section (EEPROM emulation section) from the memory definition in the .ld file.

The previous definition was:

MEMORY

{

 RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K

 FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 128K - 8K - 16

 VERSION (r) : ORIGIN = 0x0801dfe0, LENGTH = 16 /* Reserved section for firmware version */

 ROM (rx) : ORIGIN = 0x0801e000, LENGTH = 8K /* Reserved for eeprom emulation */

}

The .bin file work after loading via ST-LINK instantaneously.

The .hex, .bin and .elf works if they are uploaded from the USB bootloader after the first reset.

[Pavel A.]

The program should have self-check of integrity (CRC). This lets you verify that the download or update was successful and the image is exactly same as you expect.

Otherwise, verify manually, by reading the flash out and compare.

A flash loader app can leave the MCU in weird state. These programs can change in future without notice, even if all is good today, it can break later. Unless it is the old good ST-Link Utility which is no longer updated.

So a reset after flashing is very much desired.

Only when you verify the image and run from a known state (reset) you can expect consistent behavior.

(assuming that the program does not depend on uninitialized flash or RAM outside of the image).