STM32F4 USB DFU trying to write to external memory?

[XD]

Hello everyone,

I'm having issues with programming a STM32F429IIT using USB DFU. Im able to program it without issue with a STLinkv3 and the hardware is fully working. 

The issue is strictly when using ST-Prog, the firmware download will reach 54% and then fail. The device seems to working as indented even though it failed to complete the programming.

I believe the issue is that the externally mapped SRAM (FMC) is included in the ELF & Hex file and the programming utility tries to program it but fails. The external SRAM is only used as a display buffer so i'm not interested in filling it with data during the programming stage.

I'm not completely sure if this is the case and even less sure of how to fix it while still keeping the external SRAM memory region in the linker script.

Any help is appreciated 🙂

Linker script

/* Memories definition */
MEMORY
{
  CCMRAM        (xrw)     : ORIGIN = 0x10000000,   LENGTH = 64K
  RAM           (xrw)     : ORIGIN = 0x20000000,   LENGTH = 192K
  FLASH         (rx)      : ORIGIN = 0x8000000,   LENGTH = 2M
  /*NOR_FLASH     (rw)       : ORIGIN = 0x60000000,   LENGTH = 2M*/
  SRAM          (xrw)     : ORIGIN = 0x64000000,   LENGTH = 1M
  BACKUP_SRAM   (rw)     : ORIGIN = 0x40024000,   LENGTH = 4K

}

Relevant part of the programming log.

15:36:12:946 : sending packet nbr: 305
15:36:12:946 : downloading data
15:36:12:983 : DFU status = 0
15:36:12:983 : DFU State = 4
15:36:13:021 : DFU status = 0
15:36:13:021 : DFU State = 5
15:36:13:022 : sending packet nbr: 306
15:36:13:022 : downloading data
15:36:13:055 : DFU status = 0
15:36:13:055 : DFU State = 4
15:36:13:088 : DFU status = 0
15:36:13:088 : DFU State = 5
15:36:13:089 : Segment[0] downloaded successfully
15:36:13:089 :   Size          : 523776 Bytes
15:36:13:089 :   Address       : 0x64000000 
15:36:13:092 : DFU status = 0
15:36:13:092 : DFU State = 5
15:36:13:092 : Status: 0, State: 5
15:36:13:092 : setting the address pointer to address: 0x64000000
15:36:13:109 : DFU status = 0
15:36:13:109 : DFU State = 4
15:36:13:109 : DFU status = 1
15:36:13:109 : DFU State = 10
15:36:13:127 : DFU status = 1
15:36:13:127 : DFU State = 10
15:36:13:150 : DFU status = 1
15:36:13:150 : DFU State = 10
15:36:13:176 : DFU status = 1
15:36:13:176 : DFU State = 10
15:36:13:196 : DFU status = 1
15:36:13:196 : DFU State = 10
15:36:13:219 : DFU status = 1
15:36:13:219 : DFU State = 10
15:36:13:245 : DFU status = 1
15:36:13:245 : DFU State = 10
15:36:13:272 : DFU status = 1
15:36:13:272 : DFU State = 10
15:36:13:292 : DFU status = 1
15:36:13:292 : DFU State = 10
15:36:13:313 : DFU status = 1
15:36:13:313 : DFU State = 10
15:36:13:342 : DFU status = 1
15:36:13:342 : DFU State = 10
15:36:13:364 : DFU status = 1
15:36:13:365 : DFU State = 10
15:36:13:381 : DFU status = 1
15:36:13:381 : DFU State = 10
15:36:13:403 : DFU status = 1
15:36:13:404 : DFU State = 10
15:36:13:442 : DFU status = 1
15:36:13:442 : DFU State = 10
15:36:13:462 : DFU status = 1
15:36:13:462 : DFU State = 10
15:36:13:483 : DFU status = 1
15:36:13:483 : DFU State = 10
15:36:13:503 : DFU status = 1
15:36:13:503 : DFU State = 10
15:36:13:524 : DFU status = 1
15:36:13:524 : DFU State = 10
15:36:13:543 : DFU status = 1
15:36:13:543 : DFU State = 10
15:36:13:569 : DFU status = 1
15:36:13:569 : DFU State = 10
15:36:13:589 : DFU status = 1
15:36:13:589 : DFU State = 10
15:36:13:617 : DFU status = 1
15:36:13:617 : DFU State = 10
15:36:13:637 : DFU status = 1
15:36:13:637 : DFU State = 10
15:36:13:656 : DFU status = 1
15:36:13:656 : DFU State = 10
15:36:13:686 : DFU status = 1
15:36:13:687 : DFU State = 10
15:36:13:687 : received memory address is wrong or unsupported
15:36:13:687 : Status: errTARGET, State: dfuERROR
15:36:13:687 : Error: failed to download Segment[3]
15:36:13:687 : Error: failed to download the File

[Tesla DeLorean]

Not really clear on how you're implementing this.

The USB DFU Device would need to be one you'd have to write and be aware of your hardware. The ROM based System Loader won't support random external memories and devices.

Check what your DFU device reports for memories, and instrument to understand the interactions and failings on the STM32F4 side.

[XD]

The goal is simply to reprogram the internal memory of the processor using the built in bootloader from ST. I'm not using any external loaders nor storing any program data on any external memory besides the frame buffer.

I believe that the ELF file includes the external SRAM memory region, the programmer sees this address and "data" and attempts to write the data to it and fails since it has no idea of how to access it. 

Not sure if I'm making any sense!

[Tesla DeLorean · Accepted solution]

The ROM has no idea what pins you've connected the external memory too, or how it works.

The ELF and DFU file may well describe the addresses and data, but that doesn't help you if there is no mechanical way for that data to reach it's destination.

You would need your OWN DFU device which describes the memory regions it supports, and facilitates access too.

Not sure if either of these support external memories, there might be others for this or other STM32 platforms, but this is illustrative.

https://github.com/STMicroelectronics/STM32CubeF4/tree/master/Projects/STM324xG_EVAL/Applications/USB_Device/DFU_Standalone

https://github.com/STMicroelectronics/STM32CubeF4/tree/master/Projects/STM32469I-Discovery/Applications/USB_Device/DFU_Standalone

From the Application / Linker perspective, you're filling this space with 500 KB of data some how. If it's uninitialized / unused, you could make it a NOLOAD section so no data gets into the object file. Content could be staged in FLASH, and copied out via code you add into stm32f4xyz_startup.s

.noinit_sram (NOLOAD):
{
		. = ALIGN(4);
		*(.noinit_sram)
		*(.noinit_sram.*)
		. = ALIGN(4);
  } >SRAM

[XD]

Thanks @Tesla DeLorean, adding the NOLOAD parameter to the memory region solved my issue. I was never interested in writing data to it from the DFU. 

Why has the programming worked without any errors when using a STLinkv3, shouldn't it also try to access the "external" memory regions?