cortex-m-rt: add reset-interrupt-state feature

[rhgndf]

Some bootloaders don't disable interrupts when exiting and jumping into user code.

What should be the order to execute this with respect to set-vtor/set-sp?

[adamgreig]

Which bootloaders? This seems like a bootloader bug, although we have the set-sp and set-vtor also just to work around bootloader bugs...

[rhgndf]

I encountered this with the bootloader on py32f072 after flashing a firmware using its usb hid bootloader.

It seems like the bootloader enables the USB interrupt, SysTick and PendSV and doesn't disable it after jumping to user code, so if an interrupt fires before the user firmware data structures are set up, the interrupt handler can corrupt data or crash causing a stuck cpu.
The instructions in the bootloader before jumping are just:

  1fff01d2  ldr   r1,[r0,#4]       ; application reset handler
  1fff01d4  ldr   r0,[r0]          ; application initial MSP
  1fff01d6  msr   msp,r0
  1fff01da  bx    r1

The fix would be to enable both this feature and the set-vtor feature which seems to make it reliably boot.

[jonathanpallant]

I think you could just disable interrupts, and write code in Rust inside main to reset your peripherals? I don't think restting all the interrupts needs to be pre-main, and I don't think it needs to be in cortex-m-rt, given it's only to work-around buggy bootloaders on specific platforms.

[rhgndf]

There would still be a small window between setting vtor and disabling peripherals though. Putting it before setting vtor would be much less likely to crash since we assume that the data structures in ram are still set up for the bootloader's ISR.

Yeah I agree trying to fix every bootloader's bugs in cortex-m-rt isn't a good idea so I wanted to get some comments on this.

[adamgreig]

I think it would probably be enough to have a new feature like disable-interrupts which just runs cpsid i at the start of reset, then the remaining code could happen in the user's main function? That keeps it to a short and easily understood feature and allows the most flexibility. It could even just be in a user-defined pre_init but I can see it being helpful to have as a feature in the same way we support set-sp, set-vtor, etc.

[jannic]

Would cpsid f be needed as well on targets that support it?
(Probably not - when interrupts are disabled, any HardFault between this point and the proper initialization of the vector table must be triggered by our own startup code, so it's our responsibility to not trigger such a fault in the first place. Unlike interrupts, that could be triggered by outside events.)