Skip to main content
garry_st
Associate
June 22, 2015
Question

STM32F4xx Rebooting to bootloader when setup to boot to App.

  • June 22, 2015
  • 2 replies
  • 888 views
Posted on June 22, 2015 at 23:36

I have a F4 chip that calls ,    The function initiates a system reset request to reset the MCU.

__STATIC_INLINE void NVIC_SystemReset(void)

 

{

 

  __DSB();                                                     /* Ensure all outstanding memory accesses included

 

                                                                  buffered write are completed before reset */

 

  SCB->AIRCR  = ((0x5FA << SCB_AIRCR_VECTKEY_Pos)      |

 

                 (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |

 

                 SCB_AIRCR_SYSRESETREQ_Msk);                   /* Keep priority group unchanged */

 

  __DSB();                                                     /* Ensure completion of memory access */

 

  while(1);                                                    /* wait until reset */

 

}

with MEMRM = 0. - should map Flash to 0x0000, thus rebooting into my App.

However, the ST bootloader is called at (0 +4) = 0x1fff5163 (stbootloader).

This then trashes the SRAM value that is placed there to provide information to the App for the reason there was a reset. The STbootloader is using the SRAM as scratch pad.

My app is called by the STbloader but the RAM is now full of left overs.

Is my re-maping correct or am I missing something else. (BOOT0 is pulled low).

thanks in advance,

  Garry. 
    This topic has been closed for replies.

    2 replies

    Tesla DeLorean
    Guru
    June 23, 2015
    Posted on June 23, 2015 at 06:23

    I would expect the mapping to be irrelevant, the state of BOOT0 and BOOT1 are controlling, and are latched by the signal generated on NRST

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    garry_st
    garry_stAuthor
    Associate
    June 23, 2015
    Posted on June 23, 2015 at 21:28

    Thanks for the fast reply Clive,

       We couldn't fault the hardware, BootPins etc or the code, so we lifted the chip. And it is all good.

       Don't know why it missed behaved. ESD maybe but the usual precautions are in place and used.

     

    4Days for debugging on this. Learned a lot about how to control the booting and mapping to addr 0x000..  and a lot from the forum entries, mainly by yourself.

     Thanks again,

       Garry.