Cannot upload bootloader via USB port (DFU), but no problem via ST-LINK

[EThom.3]

Where to start...

I have mave made a bootloader (done this before), which is placed in the low end of the flash memory. The application is in the subsequent flash.

My board has a USB port and a DIP switch for forcing the BOOT input pin high. When I flip the DIP switch on, and power the board, I can connect STM32CubeProgrammer to the internal DFU bootloader via the USB port. I can also upload my application through the USB port. But when I try to upload my own bootloader, it fails. This is the output from STM32CubeProgrammer:

However, if I connect an ST-LINK programmer to the board, I can upload the very same file with no issues. Output from STM32CubeProgrammer:

Clearly, something starts to go wrong at "Not flash Memory: No erase done"

Just now, I upgraded STM32CubeProgrammer to the latest version (2.21.0), but this made no difference.

But why does it work with the ST-LINK programmer, and not through the USB port? And why can I upload the application through the USB port, but not the bootloader?

Can it have something to do with the bootloader using segments 0, 1 and 3, but not segment 2? Does the DFU bootloader dislike such things?

[Mike_ST]

Hello,

Not sure, but,

The elf file you're trying to upload probably contains a segment outside of the flash range, probably RAM (0x2000235C).

The ST-link debugger seems to be able to write into RAM, but the internal bootloader not, it seems to be able to write to the flash only.

I would try to check the linker file to output a binary in the flash address range or process the elf file to keep only the flash part.

[EThom.3]

Hi Mike,

That's interesting. I wonder why the elf file would contain data that belongs in RAM.

Thanks a lot. Will look into it.

[EThom.3]

You were absolutely right.

I generated a hex file, which doesn't contain any RAM content, and that works for the internal bootloader.

According to the map file, the RAM stuff (address 0x2000235C) that somehow ends up in the elf file, is the user heap stack. 

 *(COMMON)
                0x2000235c                        . = ALIGN (0x4)
                0x2000235c                        _ebss = .
                0x2000235c                        __bss_end__ = _ebss

.uninit_data    0x20000000        0xc
                0x20000000                        . = ALIGN (0x4)
 *(.uninit_data)
 .uninit_data   0x20000000        0xc ./Core/Src/mainFunctions.o
                0x20000000                ulBootKey
                0x2000000c                        . = ALIGN (0x4)

._user_heap_stack
                0x2000235c      0xa04
                0x20002360                        . = ALIGN (0x8)
 *fill*         0x2000235c        0x4 
                [!provide]                        PROVIDE (end = .)
                0x20002360                        PROVIDE (_end = .)
                0x20002560                        . = (. + _Min_Heap_Size)
 *fill*         0x20002360      0x200 
                0x20002d60                        . = (. + _Min_Stack_Size)
 *fill*         0x20002560      0x800 
                0x20002d60                        . = ALIGN (0x8)

Why it ends up there is a mystery to me. But at least now I have a work-around.

I have had a close look at the linker scripts, and the main differences are the flash start addresses, and that the flash in my bootloader is split into two parts.

/* Memories definition */
MEMORY
{
  FIXEDRAM (xrw)  : ORIGIN = 0x20000000,   LENGTH = 32
  RAM    (xrw)    : ORIGIN = 0x20000020,   LENGTH = 131040
  FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 65280
  IDFLASH   (r)    : ORIGIN = 0x800FF00,   LENGTH = 256
}

(...)

  /* Identification string for bootloader */
  .idsection (READONLY) :
  {
    . = ALIGN(4);
    __idsection_start__ =  .;
    KEEP (*(.idsection*))
    __idsection_end__ = .;
  } > IDFLASH

(...)

  /* Uninitialized data section */
  .uninit_data (NOLOAD) :
  {
    . = ALIGN(4);
    *(.uninit_data)
    . = ALIGN(4);
  } >FIXEDRAM

But I can't see why this would make the heap end up in the elf file.

Or... should my .uninit_data section have been in the ..._RAM.ld file instead?

[EThom.3 · Accepted solution]

Problem solved. It would seem that the sections in the linker script were in the wrong order. After I moved the sections I added (.idsection and .uninit_data) to other positions in the file, the linker no longer tries to add the user heap to the .elf file.

@Mike_ST thank you for the tip with the linker file.