Hello!
I’m trying to debug the i.MX7D Cortex-M4 core on an Aster carrier board with a Colibri i.MX7D SOM using Segger J-Link debugger (the EDU Mini version) and GDB.
J-Link is able to correctly detect and attach to the Cortex-M4 and open a GDB server session.
On GDB I’m able to halt and reset the target, but I cannot load any .elf file. When loading a simple freertos hello world demo .elf, communication timeout expires and J-Link disconnects from the target. The error is the following:
ERROR: Communication timed out: Requested 4 bytes, received 0 bytes !
Full log is below:
GDB Server log:
JLinkGDBServer -device MCIMX7D7_M4 -if JTAG -speed auto -JTAGConf -1,-1 -scriptfile NXP_iMX7D_Connect_CortexM4.JLinkScript
SEGGER J-Link GDB Server V6.32b Command Line Version
JLinkARM.dll V6.32b (DLL compiled May 8 2018 18:28:22)
Command line: -device MCIMX7D7_M4 -if JTAG -speed auto -JTAGConf -1,-1 -scriptfile NXP_iMX7D_Connect_CortexM4.JLinkScript
-----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: yes
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: NXP_iMX7D_Connect_CortexM4.JLinkScript
J-Link settings file: none
------Target related settings------
Target device: MCIMX7D7_M4
Target interface: JTAG
Target interface speed: auto
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link EDU Mini V1 compiled Mar 29 2018 17:48:40
Hardware: V1.00
S/N: 801002622
Feature(s): GDB, FlashBP
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...
J-Link found 1 JTAG device, Total IRLen = 4
JTAG ID: 0x5BA00477 (Cortex-M4)
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00912724 (Data = 0xF04FE7FE)
Read 2 bytes @ address 0x00912724 (Data = 0xE7FE)
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x00912724)
Downloading 576 bytes @ address 0x00000000
Downloading 14796 bytes @ address 0x1FFF8000
ERROR: Communication timed out: Requested 4 bytes, received 0 bytes !
Downloading 8 bytes @ address 0x1FFFB9CC
Downloading 4 bytes @ address 0x1FFFB9D4
Downloading 4 bytes @ address 0x1FFFB9D8
Downloading 108 bytes @ address 0x1FFFB9DC
Writing register (PC = 0x1FFF80B4)
WARNING: Target connection lost.
GDB log:
arm-none-eabi-gdb armgcc/debug/hello_world.elf
GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from armgcc/debug/hello_world.elf...done.
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
0x00912724 in ?? ()
(gdb) monitor halt
(gdb) load
Loading section .interrupts, size 0x240 lma 0x0
Loading section .text, size 0x39cc lma 0x1fff8000
Loading section .ARM, size 0x8 lma 0x1fffb9cc
Loading section .init_array, size 0x4 lma 0x1fffb9d4
Loading section .fini_array, size 0x4 lma 0x1fffb9d8
Loading section .data, size 0x6c lma 0x1fffb9dc
Start address 0x1fff80b4, load size 15496
Transfer rate: 27 KB/sec, 2582 bytes/write.
(gdb)
Do you have any suggestion on this?is there any particular gdbinit file I need to use with the colibri i.MX7?
Hi @laura_ ,
I’ve tried it with the same steps as you did and it works but I also had some trouble. Can you please try to press the module with some force to the carrier board (even if it is already connected). Maybe this solves this timeout issue. The problem is that the JTAG connector is located below the module and it only “touches” it.
Hopefully this works for you as well.
Here the output of my setup (I’ve used gdb-multiarch):
~/projects/freertos-toradex/examples/imx7_colibri_m4/demo_apps/hello_world/armgcc/debug gdb-multiarch hello_world.elf
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from hello_world.elf...done.
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
0x00000000 in __isr_vector ()
No default breakpoint address now.
(gdb) load
Loading section .interrupts, size 0x240 lma 0x0
Loading section .text, size 0x378c lma 0x1fff8000
Loading section .ARM, size 0x8 lma 0x1fffb78c
Loading section .init_array, size 0x4 lma 0x1fffb794
Loading section .fini_array, size 0x4 lma 0x1fffb798
Loading section .data, size 0x70 lma 0x1fffb79c
Start address 0x1fff80d0, load size 14924
Transfer rate: 338 KB/sec, 2487 bytes/write.
(gdb) c
Continuing.
And the output of JLinkGDBServer:
-----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: yes
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: NXP_iMX7D_Connect_CortexM4.JLinkScript
J-Link settings file: none
------Target related settings------
Target device: MCIMX7D7_M4
Target interface: JTAG
Target interface speed: auto
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link Ultra V4 compiled Apr 20 2018 16:46:34
Hardware: V4.00
S/N: 504404484
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...
J-Link found 1 JTAG device, Total IRLen = 4
JTAG ID: 0x5BA00477 (Cortex-M4)
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Hi Jaski,
I’m using the latest FreeRTOS V8.2.3, I downloaded the BSP from the freertos-toradex repo, branch colibri-imx7-m4-freertos-v8.
J-Link version is V6.32b, GDB from the GNU arm embedded toolchain V7 (tried also with gdb-multiarch V7.11.1).
Hello Stefan,
since I already had some issues with those pins I already made sure to press the SoM to the carrier. The timeout issue is still there unfortunately. I’ll do some other tests pushing the module and get back to you.
I forgot to mention that I’m opening the GDB server session with the cortex-m4 running and the cortex-A7 stopped at u-boot. Do I need to attach the debugger while also Linux is booted?
Thanks for the help,
Laura
Hello again!I tried one more time with the module pushed to the carrier (also tried using clamps, to really make sure they were pressed together with some force), J-Link still connects to the target successfully but connection is lost when trying to load the firmware with gdb. Do you have any other advice on how to fix this timeout issue?
Hello again,
I fixed the problem by using a different J-Link probe (the 20 pin EDU version, not the mini one). I guess the one I was using was faulty, apparently I’ve been unlucky with hardware recently
I still need to keep the SOM well pressed against the carrier, but the timeout problem is definitely solved.
Thank you again for your time and support,
hi @laura_
Thanks for the feedback. Yeah faulty hardware is painful.
Regarding the issue with pogo pins connection, we ware using the same pins on the colibri evaluation board for testing and there is always a stable connection.
It is possible that these pogo pins becomes dirty, which leads to a bad connection. Could you give a try by cleaning these pins and check if the connection is more stable?
