2022-01-12 01:51 AM
Hi,
I have a project with an external loader. When programming using ST-LinkV2 (SWD) it works perfectly with CubeIDE or the STM32Programmer CLI.
When trying programming the same ELF file using USB DFU connection, I get the following message, and the program exits:
"c:\program files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe" --connect port=usb1 --extload "C:\Repos\External Loader\N25Q128A_STM32F7.stldr" --download "Controller.elf" --skipErase -vb 3
-------------------------------------------------------------------
STM32CubeProgrammer v2.9.0
-------------------------------------------------------------------
Device Descriptor:
|_bLength : 0x12
|_bDescriptorType : 0x01
|_bcdUSB : 0x0100
|_bDeviceClass : 0x00
|_bDeviceSubClass : 0x00
|_bDeviceProtocol : 0x00
|_bMaxPacketSize : 0x40
|_idVendor : 0x0483
|_idProduct : 0xdf11
|_bcdDevice : 0x2200
|_iManufacturer : 0x01
|_iProduct : 0x02
|_iSerialNumber : 0x03
|_bNumConfigurations : 0x01
Configuration Descriptor:
|_bLength : 0x09
|_bDescriptorType : 0x02
|_wTotalLength : 0x36
|_bNumInterfaces : 0x01
|_bConfigurationValue : 0x01
|_iConfiguration : 0x00
|_bmAttributes : 0xc0
|_bMaxPower : 0x32
Interface Descriptor Alternate Settings: 0x00
|_bLength : 0x09
|_bDescriptorType : 0x04
|_bInterfaceNumber : 0x00
|_bAlternateSetting : 0x00
|_bNumEndpoints : 0x00
|_bInterfaceClass : 0xfe
|_bInterfaceSubClass : 0x01
|_bInterfaceProtocol : 0x02
|_iInterface : 0x04
Interface Descriptor Alternate Settings: 0x01
|_bLength : 0x09
|_bDescriptorType : 0x04
|_bInterfaceNumber : 0x00
|_bAlternateSetting : 0x01
|_bNumEndpoints : 0x00
|_bInterfaceClass : 0xfe
|_bInterfaceSubClass : 0x01
|_bInterfaceProtocol : 0x02
|_iInterface : 0x05
Interface Descriptor Alternate Settings: 0x02
|_bLength : 0x09
|_bDescriptorType : 0x04
|_bInterfaceNumber : 0x00
|_bAlternateSetting : 0x02
|_bNumEndpoints : 0x00
|_bInterfaceClass : 0xfe
|_bInterfaceSubClass : 0x01
|_bInterfaceProtocol : 0x02
|_iInterface : 0x06
Interface Descriptor Alternate Settings: 0x03
|_bLength : 0x09
|_bDescriptorType : 0x04
|_bInterfaceNumber : 0x00
|_bAlternateSetting : 0x03
|_bNumEndpoints : 0x00
|_bInterfaceClass : 0xfe
|_bInterfaceSubClass : 0x01
|_bInterfaceProtocol : 0x02
|_iInterface : 0x07
Functional Descriptor :
|_bLength : 0x09
|_bDescriptorType : 0x21
|_bmAttributes : 0x0b
|_wDetachTimeOut : 0xff
|_wTransferSize : 0x0800
|_bcdDFUVersion : 0x011a
USB speed : Full Speed (12MBit/s)
Manuf. ID : STMicroelectronics
Product ID : STM32 BOOTLOADER
SN : 00000008FFFF
FW version : 0x011a
Board : --
Device ID : 0x0449
DFU status = 0
DFU State = 9
Status: 0, State: 9
sending an abort request
DFU status = 0
DFU State = 2
setting the address pointer to address: 0x08000000
data: 2100000008
DFU status = 0
DFU State = 4
DFU status = 0
DFU State = 5
data: 2100000008
Loading Secondary Boot Loader into RAM
Loading Secondary Boot Loader into RAM ...
Does someone have any idea what went wrong? It looks like the external loader fails to load over USB DFU connection, but no error message is shown.
Any help will be appreciated,
Roy
2022-01-12 02:14 AM
2024-07-16 06:57 AM
i think i have the same problem.
External loader is working perfectly via SWD, but not via USB
I was using STM32CubeProgrammer v2.15.0
2024-07-16 07:24 AM
USB-DFU doesn't support External Loaders, the approach you're supposed to take is have your own DFU implementation that supports the features and functions of your board directly, so STM32 Cube Programmer can push a DFU file's content to the addresses you're put in it, and support with your target side implementation.
Not going to work with UART system loader either.
In your own programming app you could stage a loader in RAM that then supported whatever protocol / memory you want to support at the next stage of the upload process..
2024-07-16 07:57 AM
thanks for your reply.
I was wondering if USB-DFU + external loader is even supported, but didn't find any documentation about that.
Thanks for your clarification.
2024-07-16 08:26 AM
The other approach perhaps is to use a USB-MSC or MTP device, where you can drag-n-drop an update onto the STM32, and it becomes more agnostic to the host platform and your need to provide user experience / tools to facilitate the interaction. The Faux drive could act like the Arduino / ST-LINK model where the content goes directly to memory. Perhaps robust enough for developers, perhaps less so for end-users.
In the degree of difficulty stakes, having a portion of a larger QSPI NOR Flash as a 4KB Sector USB-MSC removable FAT drive, would be one of the easier ways to stage a firmware update image on a board. Security and Integrity can be factored in to how the staged image is accepted and utilized.
2024-07-17 05:33 AM
12:12:35:367 : setting the address pointer to address: 0x90000000
.......
12:12:35:898 : received memory address is wrong or unsupported
12:12:35:898 : Status: errTARGET, State: dfuERROR
12:12:35:899 : Error: failed to download Segment[1]
You're trying to load content into external memory.