STM32F407 DFU and STM32CubeProgrammer - Problem to load a new program - Not Erase memory

[GAJOBAR]

Hello!

I'm trying to use a firmware DFU with the STM32F407 and Emulated EEPROM to change into DFU / App or App / DFU. The DFU address is in 0x08000000, the Emulated EEPROM address is in 0x08008000 and the Application address, on 0x0800C000.

All this steps works fine, the DFU connect with USB to the STM32CubeProgrammer and I can load a first code. Then it jump right to the Application, run it good, and I can go back to the DFU without problems. The problems comes when a trying to load another program after the first load previously.

I could find in the code of DFU, the function MEM_If_Erase_HS is never called so, it can't load a new program. The other functions, some are called like MEM_If_Write_HS (because load the first time the program) and MEM_If_Read_HS (because the verification is right). So, I don't understand or I can't find why is not called the function to erase the memory and program another code.

On the STM32CubeProgrammer, I have the error menssage:

12:10:04 : Memory Programming ...
12:10:04 : Opening and parsing file: Main_QB_STM_DFUFreeRTOS.bin
12:10:04 : File : Main_QB_STM_DFUFreeRTOS.bin
12:10:04 : Size : 39.74 KB
12:10:04 : Address : 0x0800C000
12:10:04 : Erasing memory corresponding to segment 0:
12:10:04 : Error: failed to erase memory

Has anyone had this or a similar problem to help me?

[GAJOBAR]

That's the problem! I can't load another program with the DFU. THe only way is erasing all memory, reprogram DFU and then load the program. It not have sense.

So, knowing this, I try to debug the DFU program and I found in the DFU or the USB or the STM32CubeProgrammer, that never call the function to erase the memory for re-program. But, I don't know why, because is code generated by MX so, code of STM. The DFU is a very tested code by STM, right? Or not??

[AScha.3]

I asked :

What now?  New mini-test-program can be loaded with DFU mode ?

And then load this program  again with DFU mode - works or not ?

You "answer" :

That's the problem! I can't load another program with the DFU. THe only way is erasing all memory, reprogram DFU and then load the program. It not have sense.

This is no answer to my questions. 

So again : Did you try , reprogram with only the small test-program ?

btw

We use (at company) bootloader mode very often, for service or update by customer;

the program here is about 700KB size and there are no problems reported (about 1000 boards in use).

So ... think about, where the "problem" might come from.

[GAJOBAR]

Maybe I expressed myself wrong or you don't understand me. You have Skype o I can write you on WhatsApp/Telegram??

Did you try , reprogram with only the small test-program ?

My answer is OK. Using a blinking LED program (mini-test-program) and I have always the same result. Blinking_LED_v0.1 :

1. DFU wainting program
2. DFU loading Blinking_LED_v0.1
3. Blinking_LED_v0.1 working good
4. Again, DFU wainting program
5. DFU loading Blinking_LED_v0.1 (ERROR!)

ERROR:

12:10:04 : Memory Programming ...
12:10:04 : Opening and parsing file: Blinking_LED_v0.1.bin
12:10:04 : File : Blinking_LED_v0.1.bin
12:10:04 : Size : 39.74 KB
12:10:04 : Address : 0x0800C000
12:10:04 : Erasing memory corresponding to segment 0:
12:10:04 : Error: failed to erase memory

The error is, the DFU can't erase the memory. Why? I don't know, but I know the function to erase memory, is never called. I don't know why. I don't understand why. The code is generated by MX, so STM code, not mine.

One important thing is that I use DFU by firmware. I am not using the internal DFU (because I need it that way, depending on the project requirements).

[AScha.3]

>One important thing is that I use DFU by firmware. I am not using the internal DFU

So you dont use boot0 -> bootloader mode ???? You didnt tell this.

[GAJOBAR]

Yes, in the explanation of post "I'm trying to use a firmware DFU with the STM32F407 and Emulated EEPROM..."

By requirement, we need to implement various functions in reboot, for differents DFU modes and others. So, we need a firmware DFU or implements the DFU STM by firmware.

[AScha.3]

OMG - so i always was thinking, the internal bootloader dont work.. (this is the firmware for me ! )

But then its not about it, its your custom bootloader software !

So look there, it doing something wrong. obviously.

+ still i dont understand this : >The DFU code is not my code, is code of STM.

But this tells me, you use the bootoader - but you dont , right ?

[GAJOBAR]

The firmware DFU is using the USB like DFU configured on MX. ST is the creator of this tools, so, the code is from they. Like you recommendation, we are in the step to make work the simple DFU (firmware DFU from MX without changes) and the problem come from this, code make by ST.

[AScha.3]

So try : boot0 hi, reset, start real firmware bootloader  -> CubeProgrammer . - Flash working then ?

[GAJOBAR]

No, because not have drivers or is not detected (we was prove many drivers and it not detect). With the firmware DFU, no problem. In any case, it would not be useful to us due to the conditions and modifications that we require that the internal DFU does not have. It must be yes or yes by firmware to customize.

[GAJOBAR]

Thanks, but this tips I already try before and not is that.

I was create a tiket for ST to try to solve this, because is a STM32CubeProgrammer problem and they answer me that, after recommended use the DfuSe for test another software (that didn't work for the DFU firmware), the next:

"I am not sure why this tool is not working for you. Concerning your original issue, it looks like others have encountered this issue with the function not being called. Let me talk to our development team and have them advise how to proceed."

So, it's very probably an issue on the STM32CubeProgrammer, but I'm waiting the new answer of they.