[ABANDONED] 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.

  • [ABANDONED] 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.