This PR addresses some issues with fault handling in the remote protocol that were identified as part of a set of issues @Xobs reported earlier in the year.
The first of two major issues that were occuring are that if a fault happens in the ADIv5 acceleration interface on the probe, setting remote_dp.fault non-zero, that would become a permanent error and lock the stack out of correctly handling further communication. This is addressed by making sure the fault status gets reset during request setup processing on the probe.
The second is that some errors, such as no-response, were not being properly propergated back up to BMDA. This has been addressed by a fix to adiv5_dp_recoverable_access() which solves a long standing issue with how it would (fail to) deal with a still-faulting access, and to the v3 and v4 protocol response handling to turn no-response faults back into exceptions to propagate properly. This aligns the BMDA remote protocol implementation more closely to the native firmware behaviour the architecture code is expecting.
Part of the reason to address these issues is what happens when target power is removed part way through discovery, or between discovery and attach, or even between attach and detach. In these cases, several extremely bad things would happen and the only fix would be to power cycle the probe and restart BMDA.
Detailed description
This PR addresses some issues with fault handling in the remote protocol that were identified as part of a set of issues @Xobs reported earlier in the year.
The first of two major issues that were occuring are that if a fault happens in the ADIv5 acceleration interface on the probe, setting remote_dp.fault non-zero, that would become a permanent error and lock the stack out of correctly handling further communication. This is addressed by making sure the fault status gets reset during request setup processing on the probe.
The second is that some errors, such as no-response, were not being properly propergated back up to BMDA. This has been addressed by a fix to
adiv5_dp_recoverable_access()which solves a long standing issue with how it would (fail to) deal with a still-faulting access, and to the v3 and v4 protocol response handling to turn no-response faults back into exceptions to propagate properly. This aligns the BMDA remote protocol implementation more closely to the native firmware behaviour the architecture code is expecting.Part of the reason to address these issues is what happens when target power is removed part way through discovery, or between discovery and attach, or even between attach and detach. In these cases, several extremely bad things would happen and the only fix would be to power cycle the probe and restart BMDA.
Your checklist for this pull request
Closing issues