imxrt1050 Jlink debugging woes
Dave Marples
SEGGER J-Link GDB Server V6.35d (beta) GUI Version
JLinkARM.dll V6.35d (DLL compiled Sep 17 2018 12:39:11)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 5000 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
-----Target related settings------
Target device: MIMXRT1052xxx6A
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link OpenSDA 2 compiled Jun 28 2018 09:45:18
Hardware: V1.00
S/N: 621000000
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...
Connected to target
Waiting for GDB connection...
(target remote localhost:2331 sent from gdb session)
Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x6000313E (Data = 0xF8A1F000)
Read 2 bytes @ address 0x6000313E (Data = 0xF000)
(monitor reset sent from gdb session)
Received monitor command: reset
Resetting target
(file nuttx, load sent from gdb session)
Reading all registers
Downloading 8192 bytes @ address 0x60000000
Downloading 16080 bytes @ address 0x60002000
Downloading 16016 bytes @ address 0x60005ED0
Downloading 16032 bytes @ address 0x60009D60
Downloading 11105 bytes @ address 0x6000DC00
Downloading 8 bytes @ address 0x60010764
Downloading 108 bytes @ address 0x6001076C
Writing register (PC = 0x600022c0)
(continue sent from gdb session)
Starting target CPU...
ERROR: Can not read register 15 (R15) while CPU is running
...Target halted (DBGRQ, PC = 0x00000000)
There's nothing unusual on the SWCLK or SWIO lines, and the issue remains the same for both the OpenSDA and JLinkPro probes.
Can someone who has this working please let me know what they are doing differently?
Regards
DAVE
Alan Carvalho de Assis
First of all welcome back to NuttX! I hope this time you stay ;-)
"ERROR: Can not read register 15 (R15) while CPU is running"
BR,
Alan
> You received this message because you are subscribed to the Google Groups
> "NuttX" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nuttx+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
Dave Marples
Hi Alan,
Sorry, wandered off looking at shiny things, but back again now :-) I've actually been working on some SWO/Trace analysis tooling (See https://github.com/orbcode/orbuculum) which has taken up my hobby-time, but I'm now looking at using NuttX for dayjob, so I can legitimately spend a bit of time on the project!
I have just tried again with a 'monitor reset' after loading the code, and it's certainly better, but when I CTRL-C and then restart, I get the trace below.
BTW, one thing I didn't mention in my previous note was that the fault condition seems to persist until I power cycle the CPU....I get some kind of error that the debugger can't find the CPU in the coresight config, but I need to re-run those tests to give you a trace; more later. It's always easy to blame the tools, but I'm starting to suspect something a bit unusual in the Segger config.
Regards
DAVE
<SNIP>
Downloading 108 bytes @ address 0x60010870
Writing register (PC = 0x600022c0)
Received monitor command: reset
Resetting target
Starting target CPU...
(CTRL-C from gdb session)
Debugger requested to halt target...
...Target halted (PC = 0x600053EA)
Reading all registers
Read 4 bytes @ address 0x600053EA (Data = 0xB5384770)
Read 2 bytes @ address 0x600053EA (Data = 0x4770)
(Continue from gdb session)
Starting target CPU...
ERROR: Could not start CPU core. (ErrorCode: -2)
ERROR: Can not read register 15 (R15) while CPU is running
Reading all registers
ERROR: Can not read register 0 (R0) while CPU is running
ERROR: Can not read register 1 (R1) while CPU is running
ERROR: Can not read register 2 (R2) while CPU is running
ERROR: Can not read register 3 (R3) while CPU is running
ERROR: Can not read register 4 (R4) while CPU is running
ERROR: Can not read register 5 (R5) while CPU is running
ERROR: Can not read register 6 (R6) while CPU is running
ERROR: Can not read register 7 (R7) while CPU is running
ERROR: Can not read register 8 (R8) while CPU is running
ERROR: Can not read register 9 (R9) while CPU is running
ERROR: Can not read register 10 (R10) while CPU is running
ERROR: Can not read register 11 (R11) while CPU is running
ERROR: Can not read register 12 (R12) while CPU is running
ERROR: Can not read register 13 (R13) while CPU is running
ERROR: Can not read register 14 (R14) while CPU is running
Alan Carvalho de Assis
Interesting your SWO/Trace analysis tool!
Please try "monitor reset halt", I recall I faced an issue to get it
working with GDB/OpenOCD in the past, but using direct telet to
OpenOCD worked, reported here:
https://acassis.wordpress.com/2015/05/22/using-openocd-and-gdb-to-debug-my-nuttx-port-to-lpc11xx/
patacongo
I have a problem that is probably down to sticky fingers, but I can't find my way through it. When I try the nsh example for the imxrt1050 in conjunction with JLink it will connect and flash OK, and I can step through the startup code, but either immediately, or within a few seconds, the gdb session drops out. I've tried 7.26 and current git, and I've also verified that WFI isn't in use (it's commented out in the current code). I've tried the latest SEGGER firmware and the beta firmware. This occurs both using the onboard OpenSDA debug probe (when reprogrammed for JLink use, obviously) and a JLinkPro V4.0.
Dave Marples
Yup, that bit is all done, and I've been working with this board using the JLink driver for a while now on various projects....which is why I'm a bit confuzzed what is going on here. First thought would have been a pin reconfiguration or a clock stop on sleep, but neither of those things seem to be happening. I wondered how folks who _had_ got it working were configured. After trying Alans suggestion the next step may be to go back to OpenSDA firmware to see if it's a Segger or platform issue...watch this space.
Regards
DAVE
I have a problem that is probably down to sticky fingers, but I can't find my way through it. When I try the nsh example for the imxrt1050 in conjunction with JLink it will connect and flash OK, and I can step through the startup code, but either immediately, or within a few seconds, the gdb session drops out. I've tried 7.26 and current git, and I've also verified that WFI isn't in use (it's commented out in the current code). I've tried the latest SEGGER firmware and the beta firmware. This occurs both using the onboard OpenSDA debug probe (when reprogrammed for JLink use, obviously) and a JLinkPro V4.0.
You do know that you have to burn special firmware on the board to use the J-Link right? It is available from the Segger website. This is described in more detail on the Zephyr web site: https://docs.zephyrproject.org/latest/boards/arm/mimxrt1050_evk/doc/mimxrt1050_evk.html
Gregory Nutt
> Yup, that bit is all done, and I've been working with this board using
> the JLink driver for a while now on various projects....which is why
> I'm a bit confuzzed what is going on here. First thought would have
> been a pin reconfiguration or a clock stop on sleep, but neither of
> those things seem to be happening. I wondered how folks who _had_
> got it working were configured. After trying Alans suggestion the
> next step may be to go back to OpenSDA firmware to see if it's a
> Segger or platform issue...watch this space.
>
all. I didn't do anything special other than burn the new firmware.
Dave Marples
issues, but they do relate to NuttX, honest)
Alan, et. al.,
Found it!
monitor reset halt doesn't exist on the Segger stuff, but it gave me a
clue...if I perform the following sequence in gdb (assuming
preconditions are met such as having the debug file set, being hooked to
the GDBserver etc);
monitor reset
load
continue
....then I get errant behavior which starts off with;
ERROR: Can not read register 15 (R15) while CPU is running
ERROR: Can not read register 0 (R0) while CPU is running
ERROR: Can not read register 1 (R1) while CPU is running
ERROR: Can not read register 2 (R2) while CPU is running
ERROR: Can not read register 3 (R3) while CPU is running
ERROR: Can not read register 4 (R4) while CPU is running
ERROR: Can not read register 5 (R5) while CPU is running
ERROR: Can not read register 64 (FPS31) while CPU is running
WARNING: Failed to read memory @ address 0xDEADBEEE
Interestingly, if I then send a 'monitor reset', I get, after a timeout;
Received monitor command: reset
ERROR: Could not find core in Coresight setup
...no idea how that is happening, but I'll take it as 'bad things' and
leave it at that. If I then send _another_ monitor reset sanity is
resumed. Now, If instead I try to program the chip with the following
sequence;
monitor reset
load
monitor reset
continue
...then everything appears to work perfectly....or, at least, it has so far.
From all of this I'm guessing that the prefetch buffers aren't getting
flushed after the reprogramming or something similar is going
on...perhaps cos NuttX is doing juicy things with the memory map that I
haven't looked into yet, and that's confusing gdb/JLink. I'll send a
note to the Segger folks 'cos they're the experts on this stuff.
For archival/reference purposes for anyone trying to do this inside
Eclipse in future (which is where I came into the whole mess); In the
Debug session configuration, Startup page, in the Run Commands section,
change 'Set breakpoint at:' to be __start and add 'monitor reset' into
the Run Commands box and you should be golden.
Thanks for the help guys ... just having folks around to bounce thoughts
off of is _really_ useful in these situations.
Regards
DAVE