AP_Periph bootloader issue: bl_protocol.cpp leaves CPU in PSP 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

Issue details
bl_protocol.cpp leaves CPU in PSP prior to app jump

Version
Latest version of Master

Platform
[x] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Airframe type
AP_Periph, all

Hardware type
AP_Periph targets

Logs
N/A

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: #14022