Many cortexm probes throw exceptions on RTL8710

[chapatt]

I'm attempting to add a BMP target driver for the Realtek RTL8710. I'm working on the probe function and ran into the issue that some of the other probe functions that are run first throw fatal exceptions. If I put my PROBE(rtl8710_probe) line at the top of the list in src/target/cortexm.c, it works fine.

It seems the RTL8710 doesn't like certain memory addresses read (namely 0x400743F8, 0x400E0940, 0x400E0740, 0x400FE004) in the case of the LPC15XX, SAM3X, SAM4L, and LMI probes which cause this error:
GDB:

Timeout during scan. Is target stuck in WFI?
Timeout during scan. Is target stuck in WFI?
SW-DP scan failed!

Serial debug:

Exception: SWDP ACK timeout

The LPC17XX probe does more complicated SW-DP stuff and causes:
GDB:

Ignoring packet error, continuing...
<above repeats forever>

[gsmcmullin]

I think putting the probe function first is an acceptable solution for now. We have seen a problem like this on the Cortex-A's where accessing unimplemented addresses (or addresses where the slave is clock gated) can leave the bus in a perpetual wait state. This is the first Cortex-M that has shown a problem like this and things will get more complicated if/when others exhibit this problem.

It's worth trying to wrap each probe function in a TRY_CATCH, catching the timeout and using adiv5_dp_abort(dp, ADIV5_DP_ABORT_DAPABORT) to abort the stalled bus transaction.

[chapatt]

I was unsuccessful getting an STM32F107 dev board I have running as a BMP clone, so I wasn't able to look further, yet. But I'm learning more about the RTL everyday, so I might come upon some insights--e.g., it has a bunch of memory-mapped peripheral controllers right in that 0x40000000 range which are initialized/configured by writes to a mmapped system controller and calls to functions in a ROM.

[UweBonnes]

For debugging BMP itself, I can highly recommend FTDI based probes. No need to upload a changed firmware, and debugging the probe and single stepping can be done on th PC.

[dragonmux]

Hi @chapatt, sorry this issue has gone unresolved for so long. Could you please test latest main and let us know how you get on - a lot of improvements have been made since 2018 to how failure is handled and failed reads processed, so in theory this issue should now be fixed.

We look forward to hearing back from you.

[dragonmux]

Given we've not had reports of this kind of issue with probing in quite some time, and with all the improvements that have been done to error management and recovery, we're going to close this issue as fixed. If it is not actually fixed on main, then please let us know with details and we'll re-open the issue.