[ABANDONED] Jlink pro + CX3 debugger problems

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

  • [ABANDONED] Jlink pro + CX3 debugger problems

    that I am attempting to use an Econ Denebola board which has a
    Cypress CX3 cpu with a JLink Pro debugger and eclipse debugging.

    ( Cypress CX3 =ARM926EJ-S core) (The Denebola board is powerd via an
    external 5V power supply )

    [1] The Denebola board has a number of boot modi which you can select via dip switches, if i select the default 'boot from spi flash' boot option i cannot connect with the debugger in Eclipse. The JLinkGDBServerCL console output says:

    Source Code

    1. SEGGER J-Link GDB Server V6.12g Command Line Version
    2. JLinkARM.dll V6.12g (DLL compiled Jan 27 2017 18:18:51)
    3. -----GDB Server start settings-----
    4. GDBInit file: none
    5. GDB Server Listening port: 2331
    6. SWO raw output listening port: 2332
    7. Terminal I/O
    8. port: 2333
    9. Accept remote connection: localhost only
    10. Generate logfile: off
    11. Verify download: on
    12. Init regs on
    13. start: on
    14. Silent mode: off
    15. Single run mode: on
    16. Target connection timeout: 0 ms
    17. ------J-Link related settings------
    18. J-Link Host interface: USB
    19. J-Link script: none
    20. J-Link settings file: none
    21. ------Target related settings------
    22. Target device: ARM9
    23. Target interface: JTAG
    24. Target interface speed: 1000kHz
    25. Target endian: little
    26. Connecting to J-Link...
    27. J-Link is connected.
    28. Firmware: J-Link Pro V4 compiled Jan 25 2017 15:46:53
    29. Hardware: V4.00
    30. S/N: 174300742
    31. Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
    32. Checking target voltage...
    33. Target voltage: 3.28 V
    34. Listening on TCP/IP port 2331
    35. Connecting to target...ERROR: Could not connect to target.
    36. Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...
    37. Shutting down...
    38. Could not connect to target.
    39. Please check power, connection and settings.
    Display All

    I did quite a lot of experimenting in this mode, one of the more strange observations is that if i start Jlink.exe from the command line, run 'connect' (a command which does not seem to have an explanation in the help for some reason ?) and enter ARM9/JTAG/autodetect/1000khz the connect fails. If i run 'usb' it also fails. But if I then press the reset button on the denebola board, and then run 'usb' again then it succeeds in connecting for a while, but if i keep entering 'i' i see that after a few seconds the connection fails again (note that connect never seems to works but usb does, what is the difference ??) .


    Output:

    Source Code

    1. C:\Program Files (x86)\SEGGER\JLink_V612g>jlink
    2. SEGGER J-Link Commander V6.12g (Compiled Jan 27 2017 18:19:20)
    3. DLL version V6.12g, compiled Jan 27 2017 18:18:51
    5. Connecting to J-Link via USB...O.K.
    6. Firmware: J-Link Pro V4 compiled Jan 25 2017 15:46:53
    7. Hardware version: V4.00
    8. S/N: 174300742
    9. License(s): RDI, FlashBP, FlashDL, JFlash, GDB
    10. IP-Addr: DHCP (no addr. received yet)
    11. VTref = 3.279V
    14. Type "connect" to establish a target connection, '?' for help
    15. J-Link>usb
    16. Disconnecting from J-Link...O.K.
    17. Connecting to J-Link via USB...O.K.
    18. Firmware: J-Link Pro V4 compiled Jan 25 2017 15:46:53
    19. Hardware version: V4.00
    20. S/N: 174300742
    21. License(s): RDI, FlashBP, FlashDL, JFlash, GDB
    22. IP-Addr: DHCP (no addr. received yet)
    23. VTref = 3.279V
    24. J-Link>connect
    25. Please specify device / core. : ARM9
    26. Type '?' for selection dialog
    27. Device>ARM9
    28. Please specify target interface:
    29. J) JTAG (Default)
    30. TIF>
    31. Device position in JTAG chain (IRPre,DRPre) : -1,-1 => Auto-detect
    32. JTAGConf>
    33. Specify target interface speed [kHz]. : 4000 kHz
    34. Speed>1000
    35. Device "ARM9" selected.
    38. TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
    39. TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
    40. Cannot connect to target.
    41. J-Link>usb
    42. Disconnecting from J-Link...O.K.
    43. Disconnecting from J-Link...O.K.
    44. Connecting to J-Link via USB...O.K.
    45. Firmware: J-Link Pro V4 compiled Jan 25 2017 15:46:53
    46. Hardware version: V4.00
    47. S/N: 174300742
    48. License(s): RDI, FlashBP, FlashDL, JFlash, GDB
    49. IP-Addr: DHCP (no addr. received yet)
    50. VTref = 3.279V
    51. Device "ARM9" selected.
    54. TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
    55. TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
    56. Cannot connect to target.
    Display All

    [Here i reset the board]

    Source Code

    1. J-Link>usb
    2. Disconnecting from J-Link...O.K.
    3. Disconnecting from J-Link...O.K.
    4. Connecting to J-Link via USB...O.K.
    5. Firmware: J-Link Pro V4 compiled Jan 25 2017 15:46:53
    6. Hardware version: V4.00
    7. S/N: 174300742
    8. License(s): RDI, FlashBP, FlashDL, JFlash, GDB
    9. IP-Addr: DHCP (no addr. received yet)
    10. VTref = 3.279V
    11. Device "ARM9" selected.
    14. TotalIRLen = 4, IRPrint = 0x01
    15. CP15.0.0: 0x41069265: ARM, Architecure 5TEJ
    16. CP15.0.1: 0x1D112112: ICache: 8kB (4*64*32), DCache: 8kB (4*64*32)
    17. Cache type: Separate, Write-back, Format C (WT supported)
    18. Found 1 JTAG device, Total IRLen = 4:
    19. #0 Id: 0x07926069, IRLen: 04, IRPrint: 0x1, ARM926EJ-S Core
    20. ARM9 identified.
    21. J-Link>i
    22. JTAG Id: 0x00000000: INVALID
    23. J-Link>i
    24. JTAG Id: 0x00000000: INVALID
    25. J-Link>i
    26. JTAG Id: 0x00000000: INVALID
    27. J-Link>usb
    28. Disconnecting from J-Link...O.K.
    29. Disconnecting from J-Link...O.K.
    30. Connecting to J-Link via USB...O.K.
    31. Firmware: J-Link Pro V4 compiled Jan 25 2017 15:46:53
    32. Hardware version: V4.00
    33. S/N: 174300742
    34. License(s): RDI, FlashBP, FlashDL, JFlash, GDB
    35. IP-Addr: DHCP (no addr. received yet)
    36. VTref = 3.280V
    37. Device "ARM9" selected.
    40. TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
    41. TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
    42. Cannot connect to target.
    43. J-Link>usb
    44. Disconnecting from J-Link...O.K.
    45. Disconnecting from J-Link...O.K.
    46. Connecting to J-Link via USB...O.K.
    47. Firmware: J-Link Pro V4 compiled Jan 25 2017 15:46:53
    48. Hardware version: V4.00
    49. S/N: 174300742
    50. License(s): RDI, FlashBP, FlashDL, JFlash, GDB
    51. IP-Addr: DHCP (no addr. received yet)
    52. VTref = 3.280V
    53. Device "ARM9" selected.
    56. TotalIRLen = 4, IRPrint = 0x01
    57. CP15.0.0: 0x41069265: ARM, Architecure 5TEJ
    58. CP15.0.1: 0x1D112112: ICache: 8kB (4*64*32), DCache: 8kB (4*64*32)
    59. Cache type: Separate, Write-back, Format C (WT supported)
    60. Found 1 JTAG device, Total IRLen = 4:
    61. #0 Id: 0x07926069, IRLen: 04, IRPrint: 0x1, ARM926EJ-S Core
    62. ARM9 identified.
    63. J-Link>i
    64. JTAG Id: 0x07926069 Version: 0x0 Part no: 0x7926 Man. Id: 0034
    65. J-Link>i
    66. JTAG Id: 0x07926069 Version: 0x0 Part no: 0x7926 Man. Id: 0034
    67. J-Link>i
    68. JTAG Id: 0x07926069 Version: 0x0 Part no: 0x7926 Man. Id: 0034
    69. J-Link>i
    70. JTAG Id: 0x07926069 Version: 0x0 Part no: 0x7926 Man. Id: 0034
    71. J-Link>i
    72. JTAG Id: 0x07926069 Version: 0x0 Part no: 0x7926 Man. Id: 0034
    73. J-Link>i
    74. JTAG Id: 0x00000000: INVALID
    75. J-Link>i
    76. JTAG Id: 0x00000000: INVALID
    77. J-Link>
    Display All


    Not sure what to think of that, is the connection 'unstable', does the chip makes itself 'unavailable' somehow over JTAG, ... ?

    [2] With that last idea in mind i changed to bootmode to start in USB boot mode (so normal application SW will not be started). Using Jlink.exe with the steps above pressing i now the connection seems to be stable(r) when using the USB command (pressing i keeps working it seems).

    And if I try connecting in Eclipse it also works a "little bit". By that i mean i reach the initial breakpoint in main, i can single step there, but as soon as i step over something or press Resume (F8), 95% of the time it will not work and i will get an error:

    Starting target CPU...
    ERROR: Bad JTAG communication: Write to IR: Expected 0x1, got 0x0 (TAP Command : 2) @ Off 0x5.

    Any suggestions what might cause that?

    In attachment screen shots of the eclipse debug attempt and the jlink
    log file corresponding to that attempt....
    Images

    • Eclipse001.jpg

      269.57 kB, 1,924×1,104, viewed 601 times

    • Eclipse002.jpg

      267.66 kB, 1,924×1,104, viewed 567 times

    • Eclipse003.jpg

      219.69 kB, 1,924×1,104, viewed 525 times
    Files

    The post was edited 1 time, last by BramPeeters ().

  • Hi,

    With that last idea in mind i changed to bootmode to start in USB boot mode (so normal application SW will not be started). Using Jlink.exe with the steps above pressing i now the connection seems to be stable(r) when using the USB command (pressing i keeps working it seems).
    And if I try connecting in Eclipse it also works a "little bit". By that i mean i reach the initial breakpoint in main, i can single step there, but as soon as i step over something or press Resume (F8), 95% of the time it will not work and i will get an error:


    Lets give it a try without eclipse:
    When using J-Link Commander, can you can also debug a target application:

    • Start J-Link Commander (jlink.exe)
    • Type "connect" in order to start a debug session
    • Type in the target device name if asked (Or type "?" for a target selection Dialog)
    • Choose the correct target interface (JTAG)
    • Use a valid speed (Please note: ARM926EJ-S only support speeds up to a 1/8 - 1/6 of the current clock speed, therefore you probably need to use a speed of 4 - 50 kHz at the start of a session)
    • You should now be successfully connected.
    • It is now possible to program a binary file via the >loadfile< command
    • The commands >r<, >g<, >h<, >s< can be used for reset, go, halt and step.
    • Breakpoints can be set by using the >setbp< command.
    • >regs< shows the current status of the CPU registers if the CPU is halted
    • >disassemble< can be used in order to show the disassembly of the current and the next instructions.
    If anything fails, could you please post a screenshot of the complete session?


    Best regards,
    Niklas
    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.

  • >Use a valid speed (Please note:
    ARM926EJ-S only support speeds up to a 1/8 - 1/6 of the current clock
    speed, therefore you probably need to use a speed of 4 - 50 kHz at the
    start of a session)

    What is this "current clock speed" are you referring to here ? CPU core clock speed ?
    Anyway i tried with 50 Khz in Eclipse and it does not seem to make a difference.
    I also tried the jlink approach using breakpoint positions i took from eclipse. Not sure how i can figure out of a breakpoint needs to be in A or T mode (I took A).

    From what i can tell it looked a lot like a 'good' run when using eclipse (after i reset the board in the beginning), but he ran into the error before hitting the 3th breakpoint.
    I still need to retry a few times to see if i have consistent results for the first 2 breakpoints (which might indicate that something in the SW is interfering with JTAG (?)) or that it is random, but i have already included my jlink commands and the log file in attachment.
    Files

  • Hi,


    does the chip makes itself 'unavailable' somehow over JTAG

    Form what I can see in the log files, it indeed seems so that the application running on the CPU does sth. like which stops communication via JTAG.
    Most likely its one of the following:
    -> The application re-configures the pins used for JTAG
    -> The application enters some kind of low-power mode.

    Does the issue occur when using a very stripped-down application, for example a LED-blinky?


    Best regards,
    Niklas
    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.

  • Hi,

    Indeed, you are right, it turns out the SW puts the chip in 'suspend' after a while so that explains why the JTAG connection is lost, and why it does not work if i set the bootmode to use the application present in flash (which will do the same).

    I also tried a few more times using jlink.exe directly and these always seem to be "good" runs, i can step 's', or run 'g' and hit the next breakpoint without running into the problem (until he goes into suspend but ok) of:
    ERROR: Bad JTAG communication: Write to IR: Expected 0x1, got 0x0 (TAP Command : 2) @ Off 0x5.

    So I guess now it is time to look at eclipse again ?

    I did some experiments to try an get a better idea about what works and what does not.
    So far i seem to have the following confusing results.
    The code i am using for reference:
    C:

    C Source Code

    1. int main (void)
    2. {
    3. CyU3PIoMatrixConfig_t io_cfg;
    4. CyU3PReturnStatus_t status = CY_U3P_SUCCESS;
    6. /* Initialize the device */
    7. status = CyU3PDeviceInit (NULL);
    8. if (status != CY_U3P_SUCCESS)
    9. {
    10. goto handle_fatal_error;
    11. }
    14. status = CyU3PDeviceCacheControl (CyTrue, CyFalse, CyFalse);
    Display All


    Mixed c/asm

    C Source Code

    1. 400211f8: push {r11, lr}
    2. 400211fc: add r11, sp, #4
    3. 40021200: sub sp, sp, #48 ; 0x30
    4. 2018 CyU3PReturnStatus_t status = CY_U3P_SUCCESS;
    5. 40021204: mov r3, #0
    6. 40021208: str r3, [r11, #-8]
    7. 2023 status = CyU3PDeviceInit (NULL);
    8. 4002120c: mov r0, #0
    9. 40021210: bl 0x4000d7c4 <CyU3PDeviceInit>
    10. 40021214: str r0, [r11, #-8]
    11. 2024 if (status != CY_U3P_SUCCESS)
    12. 40021218: ldr r3, [r11, #-8]
    13. 4002121c: cmp r3, #0
    14. 40021220: beq 0x40021228 <main+48>
    15. 2026 goto handle_fatal_error;
    16. 40021224: b 0x400212c8 <main+208>
    17. 2034 status = CyU3PDeviceCacheControl (CyTrue, CyFalse, CyFalse);
    18. 40021228: mov r0, #1
    19. 4002122c: mov r1, #0
    20. 40021230: mov r2, #0
    21. 40021234: bl 0x4000ddd4 <CyU3PDeviceCacheControl>
    Display All


    In can use either step into or step over without problems to get to the 'status = CyU3PDeviceInit (NULL);' line.
    (I have a breakpoint on 0x40021234)
    At this point if:
    - I use step over 95% chance i will run into the error (see Jlink20170208_1625_StepToStepOver_Error.log)
    - I use step into to go into the function, and then press Resume i will run into the error (Jlink20170208_1627_StepToStepIntoGo_Error.log) (did not try enough to get an idea of the chance, probably also the same 95%)
    - I use resume it works fine all of the time it seems , it just halts at the configured breakpoint at 0x40021234 (this would match with what i do in JLink.exe i think) (see Jlink20170208_1628_StepToGo_OK.log)

    So how do the step over or step into + go operations differ from the resume to the next breakpoint operation ?
    Files

  • Hi,


    So how do the step over or step into + go operations differ from the resume to the next breakpoint operation ?

    -> Interrupts are suppressed during stepping.
    -> (Independent units like DMAs etc continue to run while the CPU is halted)
    -> The J-Link software emulates the steps and writes back the registers etc before the CPU is let run the next time.
    You can test if this influences the behavior by unchecking the checkbox "Allow instruction set simulation" in the tab "Settings" of the J-Link control panel.

    Best regards,
    Niklas
    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.