Detailed description
- This is (another) bugfix to #2072.
- The existing problem is a possible firmware crash in remote protocol.
- This PR solves it by adding a NULL check.
BMDA with ADIv5 acceleration always has the ensure_idle method present, regardless of JTAG or SWD or auto transport, and will send !JI# as implemented.
BMP will then invoke the remote_dp (structure present in SRAM) function pointer .ensure_idle() which for SWD-only is a NULL pointer, which for all STM32 platforms aliases to Initial_MSP of bootloader or firmware and crashes (as a forced HardFault, escalated from UsageFault). On STM32F4 it is also catchable by MPU as a MemManage fault.
If this BMP had done any remote JTAG scan (!JS# initialize), then the pointer is good and points to adiv5_jtag_ensure_idle(), which I'm not sure is valid to perform in consequent remote SWD operation on SWJ+BSCAN chips. Question: zero out the pointer during SWD !SS# initialize? (now that it is checked and it is safe to)
Stack backtrace spoiler
(gdb) bt
#0 systick_spinner () at ../src/platforms/common/syscalls.c:148
#1 0x08022640 in hard_fault_handler () at ../src/platforms/common/syscalls.c:164
#2 <signal handler called>
#3 0x00000000 in ?? ()
#4 0x08006758 in remote_packet_process_jtag (packet=0x20001198 <packet_buffer>) at ../src/remote.c:254
#5 remote_packet_process (packet=packet@entry=0x20001198 <packet_buffer>) at ../src/remote.c:941
#6 0x08005b34 in consume_remote_packet (packet=packet@entry=0x20001198 <packet_buffer>) at ../src/gdb_packet.c:148
#7 0x08005b80 in gdb_packet_receive () at ../src/gdb_packet.c:198
#8 0x08005fd4 in bmp_poll_loop () at ../src/main.c:57
#9 main () at ../src/main.c:76
(gdb) vecstate
HardFault: forced due to escalated or disabled configurable fault (see below)
UsageFault due to bad T or IT bits in EPSR
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)
- 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 (another) bugfix to #2072.
* The existing problem is a possible firmware crash in remote protocol.
* This PR solves it by adding a NULL check.
BMDA with ADIv5 acceleration always has the `ensure_idle` method present, regardless of JTAG or SWD or auto transport, and will send `!JI#` as implemented.
BMP will then invoke the `remote_dp` (structure present in SRAM) function pointer `.ensure_idle()` which for SWD-only is a NULL pointer, which for all STM32 platforms aliases to Initial_MSP of bootloader or firmware and crashes (as a forced HardFault, escalated from UsageFault). On STM32F4 it is also catchable by MPU as a MemManage fault.
If this BMP had done any remote JTAG scan (`!JS#` initialize), then the pointer is good and points to `adiv5_jtag_ensure_idle()`, which I'm not sure is valid to perform in consequent remote SWD operation on SWJ+BSCAN chips. Question: zero out the pointer during SWD `!SS#` initialize? (now that it is checked and it is safe to)
<details>
<summary>Stack backtrace spoiler</summary>
```
(gdb) bt
#0 systick_spinner () at ../src/platforms/common/syscalls.c:148
#1 0x08022640 in hard_fault_handler () at ../src/platforms/common/syscalls.c:164
#2 <signal handler called>
#3 0x00000000 in ?? ()
#4 0x08006758 in remote_packet_process_jtag (packet=0x20001198 <packet_buffer>) at ../src/remote.c:254
#5 remote_packet_process (packet=packet@entry=0x20001198 <packet_buffer>) at ../src/remote.c:941
#6 0x08005b34 in consume_remote_packet (packet=packet@entry=0x20001198 <packet_buffer>) at ../src/gdb_packet.c:148
#7 0x08005b80 in gdb_packet_receive () at ../src/gdb_packet.c:198
#8 0x08005fd4 in bmp_poll_loop () at ../src/main.c:57
#9 main () at ../src/main.c:76
(gdb) vecstate
HardFault: forced due to escalated or disabled configurable fault (see below)
UsageFault due to bad T or IT bits in EPSR
```
</details>
## Your checklist for this pull request
* [x] I've read the [Code of Conduct](https://codeberg.org/blackmagic-debug/blackmagic/src/CODE_OF_CONDUCT.md)
* [x] I've read the [guidelines for contributing](https://codeberg.org/blackmagic-debug/blackmagic/src/CONTRIBUTING.md) to this repository
* [x] It builds for hardware native (see [Building the firmware](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-the-firmware))
* [x] It builds as BMDA (see [Building the BMDA](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app))
* [x] 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