jumping to the bootloader via software does not permit dfu mode

[john239955_stm1]

Posted on May 14, 2014 at 10:18

Hi

I have an STM32F4 board. When I connect a jumper to f14 and start up with a USB cable connected, the device manager of the connected PC sees a DFU Device connected and I can perform a flash upgrade over USB.

When I remove the jumper, and from my application code, jump to address 0x1FFF0004, the device does get to the bootloader, however the Device Manager on the PC reports Unknown Device.  I know that I am in the bootloader because i can upgrade over the serial comms.

The question is, what is the jumper doing for me that jumping to the bootloader from my application isnt ?

[Tesla DeLorean]

Posted on May 14, 2014 at 13:51

The question is, what is the jumper doing for me that jumping to the bootloader from my application isnt ?

Mapping the ROM at ZERO

Running from HSI

No interrupts/peripherals configured

[Charles Miller]

Posted on June 05, 2014 at 23:44

Thank you for you answers in the forum, Clive. They are always VERY HELPFUL!

I, too, have the same issue John is seeing.  What do you mean by mapping ROM to zero?

[Tesla DeLorean]

Posted on June 06, 2014 at 01:11

The way the processor boots it always loads the vectors at memory address zero, this is done by shadowing the FLASH, ROM or RAM at ZERO as well it's regular location. It's a trick with logic gates, and the BOOTx pins, or a latch thereof. SYSCFG_MEMRMP

https://community.st.com/0D50X00009XkhAzSAJ

 

https://community.st.com/0D50X00009XkaYxSAJ

 

https://community.st.com/0D50X00009Xka1fSAB

 

Edit: Fixing DEAD LINKs, original post from Jun 5 2014

[Charles Miller]

Posted on June 06, 2014 at 21:06

Thanks for another very helpful answer, Clive! The addition of the ROM remap does indeed fix the issue. I agree with your previous posts that jumping to the ROM bootloader from a reset is the best way to go--no special ''system takedown'' needed!

We use IAR Workbench, and a C++ function as the reset handler, so I'd like to share how we perform this check. We carve out a RAM location with the linker command file that will not be subject to modification by startup (ie. not in .bss, .data, etc). These sentries are written by the app, and evaluated at reset. If they indicate a reboot request, we clear them, and away we go! The code for the reset handler:

void __iar_program_start()
{
if ((*(BOOT_SENTRY_1_ADDRESS) == BOOT_SENTRY_1) &&
(*(BOOT_SENTRY_2_ADDRESS) == BOOT_SENTRY_2))
{
*(BOOT_SENTRY_1_ADDRESS) = ~BOOT_SENTRY_1 + 1;
*(BOOT_SENTRY_2_ADDRESS) = ~BOOT_SENTRY_2 + 1;
enter_bootloader();
}
__disable_interrupt();
__iar_init_vfp();
__cmain();
}

And the bootloader jumper file:

MODULE bootloader_iface
SECTION `.text`:CODE:NOROOT(2)
PUBLIC enter_bootloader
enter_bootloader:
LDR R0, =0x40023844 ; RCC_APB2ENR
LDR R1, =0x00004000 ; enable SYSCFG clock
STR R1, [R0, #0]
LDR R0, =0x40013800 ; SYSCFG_MEMRMP
LDR R1, =0x00000001 ; remap ROM at zero
STR R1, [R0, #0]
LDR R0, =0x1FFF0000 ; load ROM base
LDR SP,[R0, #0] ; assign main stack pointer
LDR R0,[R0, #4] ; load bootloader address
BX R0
END

Thanks again, Clive!