IMX6Q6: Memory Read/Write not working with J-Link

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • IMX6Q6: Memory Read/Write not working with J-Link

      Hi,

      We use a custom board with IMX6Q6 to deploy u-boot or Yocto OS via USB and all works fine so far. However, when we try to debug the u-boot from Ubuntu 22.04 host, we cannot convince our J-Link Ultra+ (with 10-pin JTag connected via the J-Link Adapter CortexM intermediate board) to flash it to the external DDR3 although we use the same clock and DDR3 initialization configuration which we used when flashing the u-boot by USB.

      To check simpler things we ran command line GDB server and supplied the GDB initialization commands and could see that although the "monitor memU32 Addx = Value" command is executed by GDB without error (maybe because there is no feedback supposed for this command), it returns a failure when we try to read the same memory with "monitor memU32 Addr" command.

      When using JLinkExe to talk to IMX6Q6 we can halt and read the CPU registers, but J-Link fails when reading/writing to or from peripheral memory. The following is a snippet of J-Link output:

      Source Code

      1. SEGGER J-Link Commander V7.88d (Compiled May 24 2023 15:23:29)
      2. DLL version V7.88d, compiled May 24 2023 15:23:09
      4. Connecting to J-Link via USB...O.K.
      5. Firmware: J-Link Ultra V4 compiled Sep 22 2022 15:00:10
      6. Hardware version: V4.00
      7. J-Link uptime (since boot): N/A (Not supported by this model)
      8. S/N: 504402110
      9. License(s): RDI, FlashBP, FlashDL, JFlash, GDB
      10. VTref=3.285V
      13. Type "connect" to establish a target connection, '?' for help
      14. J-Link>connect
      15. Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect
      16. JTAGConf>
      17. Device "MCIMX6Q6" selected.
      20. Connecting to target via JTAG
      21. TotalIRLen = 13, IRPrint = 0x0101
      22. At least one of the connected devices is not JTAG compliant (IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)
      23. JTAG chain detection found 3 devices:
      24. #0 Id: 0x4BA00477, IRLen: 04, CoreSight JTAG-DP
      25. #1 Id: 0x00000001, IRLen: ?, Unknown device
      26. #2 Id: 0x2191C01D, IRLen: ?, Unknown device
      27. DPv0 detected
      28. Scanning AP map to find all available APs
      29. AP[3]: Stopped AP scan as end of AP map has been reached
      30. AP[0]: AHB-AP (IDR: 0x44770001)
      31. AP[1]: APB-AP (IDR: 0x24770002)
      32. AP[2]: JTAG-AP (IDR: 0x14760010)
      33. Iterating through AP map to find APB-AP to use
      34. AP[0]: Skipped. Not an APB-AP
      35. AP[1]: APB-AP found
      36. ROMTbl[0][0]: CompAddr: 82141000 CID: B105900D, PID: 003BB907 ETB
      37. ROMTbl[0][1]: CompAddr: 82142000 CID: B105900D, PID: 002BB906 CTI (?)
      38. ROMTbl[0][2]: CompAddr: 82143000 CID: B105900D, PID: 004BB912 TPIU
      39. ROMTbl[0][3]: CompAddr: 82144000 CID: B105900D, PID: 001BB908 CSTF
      40. ROMTbl[0][4]: CompAddr: 8214F000 CID: B105100D, PID: 000BB4A9 ROM Table
      41. ROMTbl[1][0]: CompAddr: 82150000 CID: B105900D, PID: 000BBC09 Cortex-A9
      42. Found Cortex-A9 r2p10
      43. 6 code breakpoints, 4 data breakpoints
      44. Debug architecture ARMv7.0
      45. Data endian: little
      46. Main ID register: 0x412FC09A
      47. I-Cache L1: 32 KB, 256 Sets, 32 Bytes/Line, 4-Way
      48. D-Cache L1: 32 KB, 256 Sets, 32 Bytes/Line, 4-Way
      49. System control register:
      50. Instruction endian: little
      51. Level-1 instruction cache enabled
      52. Level-1 data cache disabled
      53. MMU disabled
      54. Branch prediction disabled
      55. Memory zones:
      56. Zone: "Default" Description: Default access mode
      57. Zone: "AHB-AP (AP0)" Description: DMA like acc. in AP0 addr. space
      58. Zone: "APB-AP (AP1)" Description: DMA like acc. in AP1 addr. space
      59. Cortex-A9 identified.
      60. J-Link>h
      61. ...
      62. J-Link>ih
      63. CPU is halted (PC = 0x000027FA).
      64. J-Link>Regs
      65. PC: (R15) = 000027FA, CPSR = 800001F3 (SVC mode, THUMB FIQ dis. IRQ dis.)
      66. Current:
      67. R0 =00000000, R1 =00000000, R2 =00900000, R3 =00000800
      68. R4 =00000002, R5 =00000000, R6 =00000098, R7 =020D8000
      69. R8 =009024B4, R9 =000B0000, R10=00000000, R11=00000000, R12=00000001
      70. R13=0093FF8C, R14=00000DE9, SPSR=00000000
      71. USR: R8 =009024B4, R9 =000B0000, R10=00000000, R11=00000000, R12=00000001
      72. R13=00000000, R14=00000000
      73. FIQ: R8 =00000000, R9 =00000000, R10=00000000, R11=00000000, R12=00000000
      74. R13=00000000, R14=00000000, SPSR=000215B0
      75. IRQ: R13=00000000, R14=00000000, SPSR=24002050
      76. SVC: R13=0093FF8C, R14=00000DE9, SPSR=B9000878
      77. ABT: R13=00000000, R14=00000000, SPSR=08000475
      78. UND: R13=00000000, R14=00000000, SPSR=20041911
      79. J-Link>mem32 0x020bc000 1 <-- Reading the register to disable watchdog returns nothing
      80. J-Link>w4 0x020bc000 0x30 <-- Disabling the watchdog
      81. Writing 00000030 -> 020BC000 <-- Write fails
      82. Failed to write memory
      83. J-Link>ih
      84. CPU is halted (PC = 0x000027FA).
      85. J-Link>
      Display All
      As the log shows both the read and write operations for e.g. address 0x020bc000 (which is used to disable the watchdog in IMX6) fails.

      According to other posts in the Internet the JLink Ultra+ should work with IMX6.
      Could this problem be related to J-Link or its incompatibility with IMX6? Or this should be a problem with IMX6 itself?

    • I could figure out that it was only the WDOG1 register with address 020BC000 that could not be read by JLink. All other registers were read and written without problem.

      However I have faced another problem when trying to debug u-boot. The u-boot is built to reside in external DDR at address 0x17800000. I have a proper GDB script to initialize DDR memory and the clocks.

      This GDB script starts with the following lines:

      Source Code

      1. target remote localhost:2331
      3. monitor reset
      4. monitor halt
      5. monitor sleep 200
      7. monitor memU32 0x020bc000 = 0x30
      8. monitor memU32 0x020c4068 = 0xffffffff
      9. monitor memU32 0x020c406c = 0xffffffff
      10. monitor memU32 0x020c4070 = 0xffffffff
      11. monitor memU32 0x020c4074 = 0xffffffff
      12. ...
      Display All
      The takes place at the first line which establishes connection with GDB server. The first line results in the following output by GDB server:

      Source Code

      1. Waiting for GDB connection...Connected to 127.0.0.1
      2. GDB client (conn. 11) requested target.xml from GDB Server
      3. Reading common registers: Read register 'r0' (4 bytes) from hardware: 0x9C229000
      4. Read register 'r1' (4 bytes) from hardware: 0x00000000
      5. Read register 'r2' (4 bytes) from hardware: 0x01000000
      6. Read register 'r3' (4 bytes) from hardware: 0x01000000
      7. Read register 'r4' (4 bytes) from hardware: 0x00000000
      8. Read register 'r5' (4 bytes) from hardware: 0xFFFFFFFF
      9. Read register 'r6' (4 bytes) from hardware: 0x34FF9300
      10. Read register 'r7' (4 bytes) from hardware: 0x00000000
      11. Read register 'r8' (4 bytes) from hardware: 0x01000000
      12. Read register 'r9' (4 bytes) from hardware: 0x00000B00
      13. Read register 'r10' (4 bytes) from hardware: 0x00000000
      14. Read register 'r11' (4 bytes) from hardware: 0x00000000
      15. Read register 'r12' (4 bytes) from hardware: 0x00000000
      16. Read register 'sp' (4 bytes) from hardware: 0x24FF9300
      17. Read register 'lr' (4 bytes) from hardware: 0x910D0000
      18. Read register 'pc' (4 bytes) from hardware: 0xCC0D0000
      19. Read register 'cpsr' (4 bytes) from hardware: 0xF3010060
      20. WARNING: Failed to read memory @ address 0x17879F2C
      21. WARNING: Failed to read memory @ address 0x00000000
      22. WARNING: Failed to read memory @ address 0x00000DCC
      23. WARNING: Failed to read memory @ address 0x00000DC8
      24. WARNING: Failed to read memory @ address 0x00000DCC
      25. WARNING: Failed to read memory @ address 0x00000DC8
      26. WARNING: Failed to read memory @ address 0x00000DCC
      27. WARNING: Failed to read memory @ address 0x00000DCA
      28. WARNING: Failed to read memory @ address 0x00000DC8
      29. WARNING: Failed to read memory @ address 0x00000DCC
      30. WARNING: Failed to read memory @ address 0x00000DCA
      31. WARNING: Failed to read memory @ address 0x00000DC8
      32. WARNING: Failed to read memory @ address 0x00000DCC
      33. WARNING: Failed to read memory @ address 0x00000DC8
      34. WARNING: Failed to read memory @ address 0x00000DCC
      35. WARNING: Failed to read memory @ address 0x00000DC8
      36. WARNING: Failed to read memory @ address 0x00000DCC
      37. WARNING: Failed to read memory @ address 0x00000DCC
      38. WARNING: Failed to read memory @ address 0x00000DCC
      39. Received monitor command: reset
      40. ERROR: Could not read CP15 register.
      41. Resetting target
      42. Received monitor command: halt
      43. Halting target CPU...
      44. ...Target halted (PC = 0xFF00000E)
      Display All
      One can see that at line 20, the GDB server tries to read from external DDR memory address 0x17879F2C, however, the DDR memory is not yet initialized. This seems to lead the i.MX6 to appear in undefined state, so that even further "monitor reset" does not recover the i.MX6 (the subsequent "monitor halt" command shows that PC points to non-existing address 0xFF00000E). After this any read or write to internal peripheral address to initialize the DDR memory seems to fail. The i.MX6 recovers only by power cycle.

      Is it possible to force the GDB server not to query the yet uninitialized DDR memory address 0x17879F2C?

    • Hi,

      GDB Server only tries to read that address if GDB tells it to do so.

      You may fiddle around with the map region command:
      wiki.segger.com/J-Link_Command_Strings#map_region

      Setting the DDR to X before initialized and issue the command again later on with N to make it accessible again.

      Out of my head I cannot say if the map region command is designed to be used on the same region multiple times per session, but I would expect it to be no problem.


      BR
      Alex
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • Thanks a lot for the feedback.

      The problem was related to my attempt to use the GDB client to initialize DDR, whereas this should have been done on GDB server side.

      Now the flashing of u-boot binary via JLink debugger is almost successful. It fails only and always at the same single chunk. The relevant log is below:

      Source Code

      1. ...
      3. J-Link found 3 JTAG devices, Total IRLen = 13
      4. JTAG ID: 0x4BA00477 (Cortex-A9)
      5. Halting core...
      6. Initializing CPU registers...Connected to target
      7. Waiting for GDB connection...Connected to 127.0.0.1
      8. GDB client (conn. 13) requested target.xml from GDB Server
      10. ...
      12. Received monitor command: speed 1000
      13. Target interface speed set to 1000 kHz
      14. Received monitor command: clrbp
      15. Received monitor command: reset
      16. Resetting target
      17. Received monitor command: halt
      18. Halting target CPU...
      19. ...Target halted (PC = 0x000010A4)
      20. Received monitor command: regs
      21. PC = 000010A4, CPSR = 400001D3 (SVC mode, ARM FIQ dis. IRQ dis.)
      22. R0 = 00000004, R1 = 00003874, R2 = 00900000, R3 = 00000800
      23. R4 = 00000000, R5 = 00000000, R6 = 00000098, R7 = 020D8000
      24. USR: R8 =009024B4, R9 =000B0000, R10=00000000, R11 =00000000, R12 =00000001
      25. R13=00000000, R14=00000000
      26. FIQ: R8 =00000000, R9 =00000000, R10=00000000, R11 =00000000, R12 =00000000
      27. R13=00000000, R14=00000000, SPSR=000015B0
      28. SVC: R13=0093FF84, R14=00000DE9, SPSR=B9040878
      29. ABT: R13=00000000, R14=00000000, SPSR=08000475
      30. IRQ: R13=00000000, R14=00000000, SPSR=A4082050
      31. UND: R13=00000000, R14=00000000, SPSR=20041991
      32. Reading common registers: Read register 'r0' (4 bytes) from hardware: 0x04000000
      33. Read register 'r1' (4 bytes) from hardware: 0x74380000
      34. Read register 'r2' (4 bytes) from hardware: 0x00009000
      35. Read register 'r3' (4 bytes) from hardware: 0x00080000
      36. Read register 'r4' (4 bytes) from hardware: 0x00000000
      37. Read register 'r5' (4 bytes) from hardware: 0x00000000
      38. Read register 'r6' (4 bytes) from hardware: 0x98000000
      39. Read register 'r7' (4 bytes) from hardware: 0x00800D02
      40. Read register 'r8' (4 bytes) from hardware: 0xB4249000
      41. Read register 'r9' (4 bytes) from hardware: 0x00000B00
      42. Read register 'r10' (4 bytes) from hardware: 0x00000000
      43. Read register 'r11' (4 bytes) from hardware: 0x00000000
      44. Read register 'r12' (4 bytes) from hardware: 0x01000000
      45. Read register 'sp' (4 bytes) from hardware: 0x84FF9300
      46. Read register 'lr' (4 bytes) from hardware: 0xE90D0000
      47. Read register 'pc' (4 bytes) from hardware: 0xA4100000
      48. Read register 'cpsr' (4 bytes) from hardware: 0xD3010040
      49. Received monitor command: speed auto
      50. Select auto target interface speed (1000 kHz)
      51. Received monitor command: flash breakpoints 1
      52. Flash breakpoints enabled
      53. Received monitor command: semihosting enable
      54. Semi-hosting enabled (SVC Addr = 0x08)
      55. Received monitor command: semihosting IOClient 1
      56. Semihosting I/O set to TELNET Client
      57. Read 4 bytes @ address 0x17879F2C (Data = 0x00000000)
      58. Read 4 bytes @ address 0x1780145C (Data = 0xE8905FF0)
      59. Downloading 996 bytes @ address 0x17800000 - Verified OK
      60. Downloading 2072 bytes @ address 0x178003E8 - Verified OK
      61. Downloading 16272 bytes @ address 0x17800C00 - Verified OK
      62. Downloading 16272 bytes @ address 0x17804B90 - Verified OK
      63. Downloading 16272 bytes @ address 0x17808B20 - Verified OK
      64. Downloading 16288 bytes @ address 0x1780CAB0 - Verified OK
      65. Downloading 16288 bytes @ address 0x17810A50 - Verified OK
      66. Downloading 16288 bytes @ address 0x178149F0 - Verified OK
      67. Downloading 16256 bytes @ address 0x17818990 - Verified OK
      68. Downloading 16272 bytes @ address 0x1781C910 - Verified OK
      69. Downloading 16272 bytes @ address 0x178208A0 - Verified OK
      70. Downloading 16272 bytes @ address 0x17824830 - Verified OK
      71. Downloading 16272 bytes @ address 0x178287C0 - Verified OK
      72. Downloading 16256 bytes @ address 0x1782C750 - Verified OK
      73. Downloading 16256 bytes @ address 0x178306D0 - Verified OK
      74. Downloading 16256 bytes @ address 0x17834650 - Verified OK
      75. Downloading 16272 bytes @ address 0x178385D0 - Verified OK
      76. Downloading 16288 bytes @ address 0x1783C560 - Verified OK
      77. Downloading 16288 bytes @ address 0x17840500 - Verified OK
      78. Downloading 16256 bytes @ address 0x178444A0 - Verified OK
      79. Downloading 16288 bytes @ address 0x17848420 - Verified OK
      80. Downloading 16304 bytes @ address 0x1784C3C0 - Verified OK
      81. Downloading 16288 bytes @ address 0x17850370 - Verified OK
      82. Downloading 11592 bytes @ address 0x17854310 - Verified OK
      83. Downloading 16200 bytes @ address 0x17857058 - Verified OK
      84. Downloading 16048 bytes @ address 0x1785AFA0 - Verified OK
      85. Downloading 16160 bytes @ address 0x1785EE50 - Verified OK
      86. Downloading 16336 bytes @ address 0x17862D70 - Verified OK
      87. Downloading 8201 bytes @ address 0x17866D40 - Verify failed
      88. Downloading 24 bytes @ address 0x17868D4C - Verified OK
      89. Downloading 16248 bytes @ address 0x17868D68 - Verified OK
      90. Downloading 412 bytes @ address 0x1786CCE0 - Verified OK
      91. Downloading 12 bytes @ address 0x1786CE7C - Verified OK
      92. Downloading 5988 bytes @ address 0x1786CE88 - Verified OK
      93. Downloading 168 bytes @ address 0x1786E5EC - Verified OK
      94. Downloading 16284 bytes @ address 0x1786E694 - Verified OK
      95. Downloading 16304 bytes @ address 0x17872630 - Verified OK
      96. Downloading 14564 bytes @ address 0x178765E0 - Verified OK
      97. Downloading 48 bytes @ address 0x17879EC4 - Verified OK
      98. Downloading 1 bytes @ address 0x17879EF4 - Verified OK
      99. Downloading 144 bytes @ address 0x17879EF8 - Verified OK
      100. Downloading 24 bytes @ address 0x17879F88 - Verified OK
      101. Writing register 'pc' = 0x17800000
      Display All

      So, it fails always on this chunk:

      Source Code

      1. Downloading 8201 bytes @ address 0x17866D40 - Verify failed
      The DDR is initialized with calibrated data. So, if it always fails at the same chunk, this is probably not a problem with calibration?



      For this problematic chunk the GDB server log shows the following log:


      Source Code

      1. 03-00000000-00-00012833-002B: Downloading 8201 bytes @ address 0x17866D40
      2. 02-00000000-00-00012833-0043: TC2FFC640 012:833.111 JLINK_WriteMem(0x17866D40, 0x2009 Bytes, ...)
      3. 02-00000000-00-00012833-0052: TC2FFC640 012:833.133 Data: 70 67 61 69 6D 61 67 65 5F 76 31 00 41 6C 74 65 ...
      4. 02-00000000-00-00012833-003D: TC2FFC640 012:833.254 CPU_WriteMem(8201 bytes @ 0x17866D40)
      5. 02-00000000-00-00012941-0030: TC2FFC640 012:941.641 - 108.539ms returns 0x2009
      6. 02-00000000-00-00012941-0042: TC2FFC640 012:941.724 JLINK_ReadMem(0x17866D40, 0x2009 Bytes, ...)
      7. 02-00000000-00-00012941-003C: TC2FFC640 012:941.749 CPU_ReadMem(8201 bytes @ 0x17866D40)
      8. 02-00000000-00-00013048-0052: TC2FFC640 013:048.653 Data: 70 67 61 69 6D 61 67 65 5F 76 31 00 41 6C 74 65 ...
      9. 02-00000000-00-00013048-002B: TC2FFC640 013:048.718 - 106.999ms returns 0
      10. 03-00000000-00-00013048-0011: - Verify failed


      Is it somehow possible to check in more details which byte(s) exactly causes a mismatch between write and read? Or maybe there is some convenient way to understand what causes a mismatch?

      Any suggestion is very welcome.