Hi,
I have a i.MX53QSB. I am using JLINK's EDU version to connect to it. I am using the Linux version of the gdb server (V4.4a)

Following is my question:
My gdbinit file first connects to the target and then tries to reset it to put in a known state.
eg. .gdbinit
set remotetimeout 5
target remote localhost:2331
monitor reset

The last command should reset the board and halt it at the first instruction (if my understanding is correct). Instead the JLinkGDBServer gives out the following warnings:

WARNING: CPU not halted after Reset, halting using Halt request
WARNING: CPU could not be halted

The board continues to boot without halting.

Where do I look for the problem?

Has anyone atleast worked with JLINK on i.MX53 boards. Can they confirm it works for them?

Hi Alex,
Thanks for the Reply!

I am using an unmodified i.MX53QSB. The product page is here: freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX53QSB
I'll read the schematics for the reset pin in the meanwhile.

Update:
Looking at the Schematic from MCIMX53QSBRM (The Hardware Reference manual for I.MX53QSB) - Page 105, I see that the JTAG_nSRST pin is connected to the RESET (bar on top) pin of the CPU. So (1) is definitely not the case.

I have contacted a FreeScale rep to ask about whether SRST is connected to TRST internally. I'll update this thread as soon as I know more.

Thanks,
Jitesh

I tried to reproduce your setup on the Linux version of the package I have. Didn't work.
So, I switched to windows and was able to reset the board with it halting on the first instruction. Thanks for that.

However, I have hit another roadblock. When I set a Hardware Breakpoint to an address, the board hits the breakpoint (I know the board is halted on the breakpoint because it turns unresponsive). However, the GDBserver doesn't catch this halt. It still report the target as running.

Please see attached screenshots.

GDBClient.jpg: It shows that I set the breakpoint at the first instruction of the Linux Kernel ("monitor setbp 0x70008000"). The board is then restarted via "monitor go" and the kernel starts to boot.
SerialTerminal.jpg: It shows the kernel has halted at the appropriate breakpoint.
GDBServer.jpg: At this point, note that the server still reports the target as "Running".

Dumping registers at this point via "gdb> monitor regs" yeilds garbage values for registers. I suspect the JLINK connection is lost?


This same thing happens even when the breakpoint is set to a uboot address, so the kernel shouldn't be at fault here.
It would probably be easier for you to reproduce this once, since we have a similar environment now. Let me know whether it is reproducible.

Thanks,
Jitesh