FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Application not loading after DFU:Leave

Go to solution
PA.3
Associate

‎2021-08-26 09:10 PM

I am trying to program the STM32F401 flash on our board in DFU mode. I am using the dfu-util tool in my Linux computer.

I am using the following code to flash and jump to application code.

dfu-util -a 0 -s 0x08000000:leave -D <location-to-binary>.bin

After the flashing is done I can see through 'lsusb' command that the MCU is not out of DFU boot loader and the application code has not loaded.

When I try the leave command again it shows the below log and the above situation continues,

$dfu-util -a 0 -s 0x08000000:leave
 
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
 
Opening DFU capable USB device...
Device ID 0483:df11
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
DfuSe command mode
Submitting leave request...
Transitioning to dfuMANIFEST state

Thanks in advance for any advice or help.

Note: For my project requirements the BOOT 0 pin is always kept high throughout the process. Please advice if this is also a factor here.

#[STM32 MCUs]​  #DFU​ 

Labels:
1 ACCEPTED SOLUTION

Accepted Solutions
Go to solution
PA.3
Associate

‎2021-08-29 11:48 PM

I found the issue. I had to uncomment the #define USER_VECT_TAB_ADDRESS in the system_stm32f4xx.c file.

Basically what was happening was bootloader was looking for loadable vector address from the flash application, with the USER_VECT_TAB_ADDRESS commented the pointer to the vector address kept pointing to the bootloader vector table effectively crashing the flash application resetting the controller. With the BOOT 0 pin high it kept loading into bootloader with each reset.

View solution in original post

1 REPLY 1
Go to solution
PA.3
Associate

‎2021-08-29 11:48 PM

I found the issue. I had to uncomment the #define USER_VECT_TAB_ADDRESS in the system_stm32f4xx.c file.

Basically what was happening was bootloader was looking for loadable vector address from the flash application, with the USER_VECT_TAB_ADDRESS commented the pointer to the vector address kept pointing to the bootloader vector table effectively crashing the flash application resetting the controller. With the BOOT 0 pin high it kept loading into bootloader with each reset.

Top