AP_Periph bootloader issue: Modified bl_protocol.cpp to activate MSP prior to app jump

[geosmall]

AP_Periph bootloader issue, processor left wirh PSP active when jumping to app, as documented here https://discuss.ardupilot.org/t/ap-periph-1-0-0-stable-released/49049/100

I’ve finally been able to track down my issue in using AP_Periph bootloader with generic software targets (in my case using Arduino IDE and Arduino_Core_STM32).

I used a J-Link and Segger Ozone script to load the AP_Periph bootloader and my project target elf into memory. Once I was able to single step through the target it became clear I had two problems: (1.) global interrupt was disabled, so target interrupts were not firing. So I enabled them at the beginning of my target startup code. With that fixed I hit my next problem, (2.) CPU is left in privileged PSP stack mode by the bootloader (SPSEL bit set in CONTROL reg http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDBIBGJ.html), as Chibios uses a dual stack MSP / PSP scheme. So I was having stack corruption problems when interrupts fired.

I found this ARM post on bootloaders helpful http://www.keil.com/support/docs/3913.htm, which recommends activating MSP just before bootloader exit (ref. bullet point 7).

Once I made these two changes (modified AP_Periph bootloader to activate MSP before exit per https://github.com/geosmall/ardupilot/blob/757057fbad50b4a2b0e09819388d98283f9f7423/Tools/AP_Bootloader/bl_protocol.cpp#L266-L271, and enable interrupt in my target startup code), things proceeded to run as expected.

I would recommend modifying the AP_Periph bootloader code per above to avoid any unintended issues downstream. The bootloader presently works fine with AP targets as they also use Chibios and therefore activate PSP. I've taken a shot at a pull request for this change here.

Thanks,
George

[tridge]

nice sleuthing, and this is probably fine, but needs testing on all the MCUs we use, so F1, F3, F4, F7 and H7