AnsweredAssumed Answered

Stopping imx6 at reset vector

Question asked by scrapper on Sep 15, 2014
Latest reply on Sep 15, 2014 by Sinan Akman

Hi, I am using the DSTREAM emulator with the ARM DS5 software. The target hardware is a Frescale SABRE SD card with the imx6q processor. I connect to the target using the emulator and then set a hardware break point at address 0. Then I do a system reset from the emulator using "reset system.reset" command. But the debugger does not stop the imx6 at the reset vector. Instead, the imx6 is stopped when it is in the u-boot main loop. So, much too late to be useful. I have also tried manually asserting the POR_B line of the imx6 after setting the hardware break point and after running the imx6. Again, the debugger doesn't stop at the reset vector, but instead it stops in the main loop of u-boot. Again, too late...


To understand what's happening, I have looked at the nSRST signal on the emulator header using my scope. When I issue the "reset system.reset" command, a 100ms pulse is generated there, as expected. Then I hooked up the scope to the nTRST pin on the emulator header. To my shock, I am seeing a 5ms pulse there! This is VERY unexpected. The emulator is NOT doing this. I disconnected the emulator and asserted nSRST again. Even without the emulator, there is a pulse at the nTRST pin. So, the imx6 seems to be resetting its internal JTAG logic when it receives a POR_B. Is this a defect in the imx6? How can I prevent the internal JTAG logic from getting reset when I assert the POR_B signal?


So the main question is, how can i stop the imx6 at the reset vector? If that isn't possible, how can I stop u-boot starting from its entry point? I have tried this, too, and the DSTREAM doesn't stop there, either. It seems DSTREAM is blind for a long time after reset, then wakes up and realizes there is a break point and then stops ...