[RFC] target/cortex_m: Block extra srst asserts in target code

[galak]

This is intended to be a temporary work around for an issue where TCL scripts are toggling srst, and then the Cortex M target code is again asserting srst. On the TI LPRF (CC26xx/CC13xx) devices this results in an undebuggable state because the target code does not restore the JTAG connection. LPRF targets come out of reset in 2-pin mode and also require the ICEPick JTAG router to put the Cortex M core into the scan chain. Neither are happening after the Cortex M target code asserts srst.

Added a flag to the JTAG reset config to signal to the Cortex M routine to -not- assert srst again. srst was already handled prior, and the target has been reset and ready to debug.

Ideally, what really needs to happen for the LPRF targets is the following.

For reset halt or reset init: assert srst run TCK for 50 ms deassert srst run TCK for 50 ms switch to 4-pin mode command ICEPick to put Cortex M TAP into scan chain continue reconnecting debug halt the core

For reset run: assert srst delay deassert srst delay switch to 4-pin mode command ICEPick to put Cortex M TAP into scan chain continue reconnecting debug leave core running

The running TCK periods during the srst assert/deassert on these device is to trigger the LPRF's HIB (halt in boot) mode where the target will stop execution at a hook in the boot ROM so that debug can start at the very start of the user application. The XDS110 code today already just does this every time, but ideally this should be configurable so that other probes can trigger HIB.

And note that debug on LPRF is not very stable without using srst reset. It is common for user applications to get the device in a mode that cannot be debugged unless srst and HIB are used.

Change-Id: I424e6f66cfeee58ba17991004f6c8fd184af8099 Signed-off-by: Edward Fewell efewell@ti.com

[nanosonde]

@galak Hi! Do you have any plan to get this fix also into upstream?

[galak]

@galak Hi! Do you have any plan to get this fix also into upstream?

I don't have any plans, but I believe Edward is working on that.

[nanosonde]

Ok, I am asking, because I saw on LinkedIn that Edward changed the employer (TI>AWS) and seems to be no longer working for TI.

[galak]

Ok, I am asking, because I saw on LinkedIn that Edward changed the employer (TI>AWS) and seems to be no longer working for TI.

Ah, I wasn't aware that Ed had left TI.

[efewell]

I left TI at end of July when the group I was working in was disbanded. It wasn't clear at that time who, if anyone, would be continuing to support the code I had added to OpenOCD on behalf of TI.

I did submit the patch to OpenOCD, but was requested to file it as an RFC (request for comment), and it was not going to be accepted for merging into release master. They didn't like that it added a new option that was temporary but could be picked up by others and then need to be unrolled should the root cause be fixed.

The root cause is that the reset code can toggle the nSRST signal, but the Cortex M target code also toggles the nSRST signal. In the sequence of events, initializations needed by the LPRF family do not get run again after the second nSRST toggle leaving the target in an undebuggable state.

[efewell]

The real fix is a clean up of the reset handling to ensure that nSRST does not get "double" toggled during the reset handling, and all necessary initializations are done in order. Someone has been working on this for over a year, but it's not clear when it may be finally complete or if it does correctly handle the issue with the TI target. Documenting that concern was another reason for posting the RFC patch.

[borneoa]

There is a new fix proposal in http://openocd.zylin.com/5871 Would be good to get your feedback