Skip to main content
john239955_stm1
john239955_stm1
Visitor II
May 14, 2014
Question

jumping to the bootloader via software does not permit dfu mode

  • May 14, 2014
  • 4 replies
  • 1353 views
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 ?
    This topic has been closed for replies.

    4 replies

    Tesla DeLorean
    Tesla DeLorean
    Guru
    May 14, 2014
    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
    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Charles Miller
    Charles Miller
    Associate III
    June 5, 2014
    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
    Tesla DeLorean
    Guru
    June 5, 2014
    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

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Charles Miller
    Charles Miller
    Associate III
    June 6, 2014
    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!
    Terms & ConditionsAccessibility statement