Stopping imx6 at reset vector

[scrapper]

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 ...

[Yuri]

  The only i.MX35 of i.MX series has special so called startup mode :

"Upon reset the PC register will remain at address 0x00000000.
This means no ROM code has run so far and the state of all internal
SOC registers are untouched."

  Perhaps, the fact, that it is impossible to stop the ARM core just
after reset relates to HAB technology - to avoid ROM code hacking.

Re: Problem halting iMX6 Chips (ARM Cortex-A9) at reset

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[sinanakman]

Yuri, thanks for additional comments.

Srapper, rereading your reply, I realized my reply sounded like

I was suggesting not to use the ROM code. What I was suggesting

was to implement the loop as the first code of the boot code that

ROM code would load and run. I don't know any way not to run

ROM code out of POR for iMX6.

Yuri, the problem is not so much not being able to stop the ROM

code but rather not being able to communicate with TAP while

RESET is asserted. It just happens that by the time RESET is

de-asserted  and the JTAG probe accesses debug registers

to halt, the rom code is already booting from devices.

This is at least what my understanding is. Please correct me if

this is wrong.

Regards

Sinan Akman

[sinanakman]

Hi, on iMX6, there is no debug communication possible when RESET is asserted, so the ROM code runs until your JTAG probe can stop it.

The way I deal with the issues similar to this is to implement a loop right at the reset vector and I control the run afterwards.

Hope this helps

Sinan Akman

[scrapper]

Hi, thanks for the reply!

So there is a way to completely override the internal boot ROM of the imx6 and have it jump to your code after POR? Didn't know that ...

But this would require special hardware, where the imx6 is attached to some type of external memory and can directly fetch instructions from it ...

But, given my existing hardware, I can write a very simple program that does nothing except an infinite loop, and then load that code instead of u-boot. Once loaded, I can override it with u-boot.

[sinanakman]

Yes, you might prefer to implement your loop in uboot very early on and just sit there before rest of your uboot code is executed.You

could then halt or single steps etc.

Regards

Sinan Akman