CLT Works with STLINK, Fails with USB DFU

[C-Coder]

I've been working on my own code for using USB DFU with our device and it is failing with the downloadFile call. I decided to test with the CLT (command line tools) and am seeing similar results. If I tell STM32_Programmer_CLI.exe to use the STLINK-V3SET with my hex file, it pushes the file without issue:

However, if I put the device into USB DFU mode, it fails as such:

This failure output is the same failure output I get when running STM32CubePrgAPI - USB_Example, as well as when I run my own application.  The HEX file being used is the same in all instances. I've also tried using the corresponding ELF file. The device is an STM32H747XI and should load code at 0x08000000 as shown. I do however have a modified linker file that defines a NOINIT section at the top of the DTCM block, as well as some data that is shared between the CM4 and CM7 cores in the top of the RAM D3 block. Could these be the source of the errors when trying to use USB DFU?

Thanks,

C-Coder

[Maryem]

Hello @C-Coder ,

I tried both CLI and API methods on my side, and they worked without problems.

To investigate further, could you please provide your .hex file?

Maryem.

[C-Coder]

@Maryem is there a way to share it off of the forum? We really don't want this getting out to the world yet if possible.

Thanks,

C-Coder

[Pavel A.]

>  I do however have a modified linker file that defines a NOINIT section at the top of the DTCM block, as well as some data that is shared between the CM4 and CM7 cores in the top of the RAM D3 block. Could these be the source of the errors when trying to use USB DFU?

Yes, as the error message is "Not flash Memory : No erase done". Looks like some RAM content leaks into the hex file. Try to dump the hex file and find the culprit (and filter the problem stuff away).

Similar errors have been reported here before.

[C-Coder]

@Pavel A. I can't just remove my NOINIT stuff, nor can I remove the stuff that is shared between the cores. Those are intricate parts of our functionality. In order for us to get into the bootloader mode we need the NOINIT code at the very least. I might be able to hack a different app up that puts us into the bootloader mode just for testing. But, "Try to dump the hex file and find the culprit (and filter the problem stuff away)." doesn't tell me how I'd do what you're thinking for the test.

Thanks,

C-Coder

[Maryem]

Hello @C-Coder , 

I've sent you a message. Could you please check your DM?

Maryem.

[Pavel A.]

> I can't just remove my NOINIT stuff

Hi @C-Coder your link script and use of shared memory is OK most probably, since it programs well via ST-LINK.

But some 'traces' of RAM addresses likely get into the hex file. The ST-LINK programming path is OK with this, but the DFU path breaks. This looks like a bug in the latter. Only the flash content should be programmed on the MCU. The debugger interface can write into RAM as well, but that data is volatile and won't survive power cycle. So my idea is that the hex file can be filtered of any addresses not in the flash. For example, use any tool to convert the hex to .bin and then back to .hex with base address 0x08000000. Discard any outstanding stuff outside the flash range. If that is the "option bytes", deal with them separately.

[C-Coder]

@Pavel A. I'm not sure which app(s) support changing the format to strip out some of those sections. I did look into srec_cat.exe from srecord but it said the .hex file had no data in it. I'm sure that's just a failure of me not knowing the tool. I did however end up trying to download a different HEX file to the device (one that doesn't have the extra segments in the linker file) via the CLT and it succeeded. So I think we can definitively say that those are the root of the problem, but the bootloader should be smart enough to handle those. I hope I don't have to write my own bootloader as I don't know the format of the files themselves nor do I know the format of what needs to be written to the flash.

C-Coder

[Pavel A.]

Hopefully your file will help the CubeProgrammer team to spot and fix the bug.

[C-Coder · Accepted solution]

After speaking with @Maryem offline, it was confirmed that the extra section I'm putting in for shared communication between the CM7 and CM4 is what is/was causing the issue. I'm using SDRAM4 on our H7 device which is addressed in the 0x38000000 - 0x3800FFFF range, and this range is not accessible by the bootloader. Removing this section was not an option for me, but I was able to change my linker script to mark that area as NOLOAD. After making that change and rebuilding my hex file(s), I'm able to use the CLT and the API to push my hex files to each of the cores.

C-Coder