The typcial procedure for performing a precise reset from a JTAG Emulator on a Cortex-A9 (or really any ARM) is as follows:
- Assert System Reset (nRESET or nSRST, depending on which ARM connector standard you're using; nCPURESET in ARM's IP)
- Assert and Release Tap Reset (nTRST; nDBGRESET in ARM's IP)
- Set DBGVCR.R
- Release System Reset
This will leave the CPU halted at the reset vector, so that one may debug very early startup code.
Unfortunately, the typical iMX6 development board connects the JTAG header's reset line to the POR_B input of the CPU; indeed, a quick review of the data sheet suggests that its the only available reset input on the SoC. As is typical of power-on resets, asserting POR_B also holds the debug logic in reset, making step 3 of the above procedure impossible. No JTAG scanning works at all when POR_B is asserted. Without being able to set DBGVCR.R before releasing reset, one has no choice but to let the startup code run while the JTAG emulator performs the JTAG scans needed to halt the CPU. Even on a very fast JTAG emulator, this may take tens or hundreds of milliseconds, during which time a great volume of startup code might run.
My Question - Is there a procedure for performing a precise reset on the iMX6 from a JTAG emulator, such that the CPU remains halted at the reset vector, and the early startup code in ROM can be debugged?
I realize, of course, that there are workarounds - for example, one may modify their startup code to immediately go into an infinite loop. Once the debugger has halted the CPU, they can bypass the loop, and debug the startup code. But this is a much more awkward experience then it ought to be.
