Skip to main content
Jeffrey Shemmans
Jeffrey Shemmans
Associate
April 3, 2017
Solved

STM32F071 IAP: How to jump back from main app to bootloader?

  • April 3, 2017
  • 1 reply
  • 952 views
Posted on April 03, 2017 at 15:57

Hi,

I am using the STM32F071C8 on one of my projects and it is of at-most importance that I get the IAP working. Jumping from my bootloader code to my main app code is not a problem. I copy the vector table to memory and remap to use the SRAM with the __HAL_SYSCFG_REMAPMEMORY_SRAM function. Obviously tweaking my linker files.

I do not want to call HAL_NVIC_SystemReset from my main app because I want to preserve the state of my IO pins, while programming the new bin file, so I was thinking of jumping back to my bootloader. While it seems that I can jump back it does not seem to be stable. Sometimes I get systick issues or sometimes it is just running 'weird'. I tried to to the copy to memory and remap the vector table again and even tried to call __HAL_SYSCFG_REMAPMEMORY_FLASH without the copy but to no avail.

Any ideas what I can try to get this 'jumping' up and down up and running?

Jeff

    This topic has been closed for replies.
    Best answer by Tesla DeLorean
    Posted on April 03, 2017 at 17:22

    I guess use some effective debugging techniques to understand what the real problem is.

    You want to be careful not to call from an interrupt state. Don't have assorted interrupts firing that the code isn't ready to handle immediately. Remapping FLASH at zero should be sufficient for a boot loader residing an 0x08000000, and not copying the vectors to RAM.

    Watch what the code in your Reset Handler path is doing with respect to clocks, PLLs, peripherals, GPIO, etc.

    If the boot loader, contractually, doesn't expect random interrupts to be firing, make sure to tear down all those settings prior to the transfer of control back to the loader. Expect the SRAM and stack settings to be unique and different.

    1 reply

    Tesla DeLorean
    Tesla DeLoreanBest answer
    Guru
    April 3, 2017
    Posted on April 03, 2017 at 17:22

    I guess use some effective debugging techniques to understand what the real problem is.

    You want to be careful not to call from an interrupt state. Don't have assorted interrupts firing that the code isn't ready to handle immediately. Remapping FLASH at zero should be sufficient for a boot loader residing an 0x08000000, and not copying the vectors to RAM.

    Watch what the code in your Reset Handler path is doing with respect to clocks, PLLs, peripherals, GPIO, etc.

    If the boot loader, contractually, doesn't expect random interrupts to be firing, make sure to tear down all those settings prior to the transfer of control back to the loader. Expect the SRAM and stack settings to be unique and different.

    Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
    Jeffrey Shemmans
    Jeffrey ShemmansAuthor
    Associate
    April 4, 2017
    Posted on April 04, 2017 at 10:50

    Hi Clive,

    Thanks for the advise, much appreciated!

    I think I found the root cause of my issue and it seems that is was the DMA

    that I want to use with I2C1 in my main app. When I disabled the DMA of my

    I2C completely the problem went away, which may point to some other issue

    with the I2C / DMA, but that might be a question for another day.

    Regards

    On Mon, Apr 3, 2017 at 5:23 PM, Clive One <st-microelectronics@jiveon.com>

    Terms & ConditionsAccessibility statement