Feature: BMP platform Cortex-M exception handlers #1957

ALTracer commented 2024年10月12日 18:31:23 +02:00 (Migrated from github.com)

Detailed description

• This is a new feature.
• The existing problem is BMPs hanging upon a HardFault etc. with no indication of that happening.
• This PR solves it by overriding default libopencm3-provided weak blocking_handler()'s with meaningful handlers which set a morse message and spin the systick (because of priority) for 10 seconds then reboot the probe.

I'm not sure if platform_request_boot() to request "stay in DFU" is better than just rebooting the probe, or if USB D+ pulse low is needed to trigger re-enumeration on some platforms, so I coded a direct scb_reset_system() instead. Future PRs could unwind the stack (I have tried implementing just that) and/or record crash dumps to SRAM or SPI flash or UART. If MPU is enabled by platform, to e.g. catch NULL dereferences, then there's a simple handler for that, too. Platforms should enable separate SCB->SHCSR BusFault and UsageFault bits for this code to distinguish between them.

Note I don't spin the UART/DMA/TIM or USB device IRQ handlers, but it technically could also be done to keep UART DMA and USB (DFU runtime stub, CDC-ACM, suspend/reset) working for a while for logging purposes. Notably sys_tick_handler() on native indirectly checks for Vtpwr undervoltage. I have not tested how this behaves yet.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA) and should not affect it
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

## Detailed description * This is a new feature. * The existing problem is BMPs hanging upon a HardFault etc. with no indication of that happening. * This PR solves it by overriding default libopencm3-provided weak `blocking_handler()`'s with meaningful handlers which set a morse message and spin the systick (because of priority) for 10 seconds then reboot the probe. I'm not sure if `platform_request_boot()` to request "stay in DFU" is better than just rebooting the probe, or if USB D+ pulse low is needed to trigger re-enumeration on some platforms, so I coded a direct `scb_reset_system()` instead. Future PRs could unwind the stack (I have tried implementing just that) and/or record crash dumps to SRAM or SPI flash or UART. If MPU is enabled by platform, to e.g. catch NULL dereferences, then there's a simple handler for that, too. Platforms *should* enable separate `SCB->SHCSR` BusFault and UsageFault bits for this code to distinguish between them. Note I don't spin the UART/DMA/TIM or USB device IRQ handlers, but it technically could also be done to keep UART DMA and USB (DFU runtime stub, CDC-ACM, suspend/reset) working for a while for logging purposes. Notably `sys_tick_handler()` on `native` indirectly checks for Vtpwr undervoltage. I have not tested how this behaves yet. ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://github.com/blackmagic-debug/blackmagic/blob/main/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://github.com/blackmagic-debug/blackmagic/blob/main/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (see [Building the firmware](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-firmware)) * [x] It builds as BMDA (see [Building the BMDA](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) and should not affect it * [ ] I've tested it to the best of my ability * [x] My commit messages provide a useful short description of what the commits do ## Closing issues

This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.

You are not authorized to merge this pull request.