[SOLVED] SystemView can't share J-Link with other Segger apps (Windows)

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

  • [SOLVED] SystemView can't share J-Link with other Segger apps (Windows)

    According to the documentation:
    Q: Can I use the SystemView Application while I am debugging my application?
    A: Yes. SystemView can run in parallel to a debugger and do continuous recording. To
    make sure data can be read fast enough, configure the debugger connection to a high
    interface speed (≥ 4 MHz).
    I'm running SystemView on Windows 10, and when no other JLink client is running I can monitor the target (RP2040) with no problem.

    But if another JLink client is running (for example, JLinkGdbServer or JLink Commander) then SystemView fails.
    Even something as simple as running JLink Commander and leaving it idle (i.e. not even connecting to the target) is enough to prevent SystemView from working.

    The SystemView log is shown below. As can be seen, when JLink Commander is running, SystemView fails - but beforehand and aftewards, SystemView has no problem.
    (Running JLInkGdbServer instead of JLink Commander produces similar results.)

    Is this a known issue, or a misunderstanding on my part?


    Source Code

    1. ---- JLink Commander *not* running ----
    2. 16:09:55 - JLink: Device "RP2040_M0_0" selected.
    3. 16:09:55 - JLink: ConfigTargetSettings() start
    4. 16:09:55 - JLink: J-Link script: ConfigTargetSettings()
    5. 16:09:55 - JLink: ConfigTargetSettings() end
    6. 16:09:55 - JLink: Found SW-DP with ID 0x0BC12477
    7. 16:09:55 - JLink: DPIDR: 0x0BC12477
    8. 16:09:55 - JLink: Scanning AP map to find all available APs
    9. 16:09:55 - JLink: AP[1]: Stopped AP scan as end of AP map has been reached
    10. 16:09:55 - JLink: AP[0]: AHB-AP (IDR: 0x04770031)
    11. 16:09:55 - JLink: Iterating through AP map to find AHB-AP to use
    12. 16:09:55 - JLink: AP[0]: Core found
    13. 16:09:55 - JLink: AP[0]: AHB-AP ROM base: 0xE00FF000
    14. 16:09:55 - JLink: CPUID register: 0x410CC601. Implementer code: 0x41 (ARM)
    15. 16:09:55 - JLink: Found Cortex-M0 r0p1, Little endian.
    16. 16:09:55 - JLink: FPUnit: 4 code (BP) slots and 0 literal slots
    17. 16:09:55 - JLink: CoreSight components:
    18. 16:09:55 - JLink: ROMTbl[0] @ E00FF000
    19. 16:09:55 - JLink: ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS
    20. 16:09:55 - JLink: ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT
    21. 16:09:55 - JLink: ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB
    22. 16:09:56 - TRACE START Event recorded.
    23. 16:09:58 - TRACE STOP Event recorded.
    24. 16:09:58 - Target stopped recording.
    25. ---- JLink Commander running, *not* connected ----
    26. 16:10:24 - JLink: Device "RP2040_M0_0" selected.
    27. 16:10:24 - JLink: ConfigTargetSettings() start
    28. 16:10:24 - JLink: J-Link script: ConfigTargetSettings()
    29. 16:10:24 - JLink: ConfigTargetSettings() end
    30. 16:10:24 - JLink: Found SW-DP with ID 0x0BC12477
    31. 16:10:24 - JLink: DPIDR: 0x0BC12477
    32. 16:10:24 - JLink: Scanning AP map to find all available APs
    33. 16:10:24 - JLink: AP[1]: Stopped AP scan as end of AP map has been reached
    34. 16:10:24 - JLink: AP[0]: AHB-AP (IDR: 0x04770031)
    35. 16:10:24 - JLink: Iterating through AP map to find AHB-AP to use
    36. 16:10:24 - JLink: AP[0]: Core found
    37. 16:10:24 - JLink: AP[0]: AHB-AP ROM base: 0xE00FF000
    38. 16:10:24 - JLink: CPUID register: 0x410CC601. Implementer code: 0x41 (ARM)
    39. 16:10:24 - JLink: Found Cortex-M0 r0p1, Little endian.
    40. 16:10:24 - JLink: FPUnit: 4 code (BP) slots and 0 literal slots
    41. 16:10:24 - JLink: CoreSight components:
    42. 16:10:24 - JLink: ROMTbl[0] @ E00FF000
    43. 16:10:24 - JLink: ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS
    44. 16:10:24 - JLink: ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT
    45. 16:10:24 - JLink: ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB
    46. 16:10:44 - ERROR: Could not find RTT Control Block.
    47. Timeout: 20000 ms
    48. ---- JLink Commander running, connected ----
    49. 16:11:06 - JLink: Device "RP2040_M0_0" selected.
    50. 16:11:06 - JLink: ConfigTargetSettings() start
    51. 16:11:06 - JLink: J-Link script: ConfigTargetSettings()
    52. 16:11:06 - JLink: ConfigTargetSettings() end
    53. 16:11:06 - JLink: Found SW-DP with ID 0x0BC12477
    54. 16:11:06 - JLink: DPIDR: 0x0BC12477
    55. 16:11:06 - JLink: Scanning AP map to find all available APs
    56. 16:11:06 - JLink: AP[1]: Stopped AP scan as end of AP map has been reached
    57. 16:11:06 - JLink: AP[0]: AHB-AP (IDR: 0x04770031)
    58. 16:11:06 - JLink: Iterating through AP map to find AHB-AP to use
    59. 16:11:06 - JLink: AP[0]: Core found
    60. 16:11:06 - JLink: AP[0]: AHB-AP ROM base: 0xE00FF000
    61. 16:11:06 - JLink: CPUID register: 0x410CC601. Implementer code: 0x41 (ARM)
    62. 16:11:06 - JLink: Found Cortex-M0 r0p1, Little endian.
    63. 16:11:06 - JLink: FPUnit: 4 code (BP) slots and 0 literal slots
    64. 16:11:07 - JLink: CoreSight components:
    65. 16:11:07 - JLink: ROMTbl[0] @ E00FF000
    66. 16:11:07 - JLink: ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS
    67. 16:11:07 - JLink: ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT
    68. 16:11:07 - JLink: ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB
    69. 16:11:07 - TRACE START Event recorded.
    70. 16:11:07 - Warning: Failed to get RTT status.
    71. 16:11:07 - Warning: Recorder encountered an error. Recording stopped.
    72. 16:11:07 - Warning: Error (-162) during record analysis
    73. 16:11:07 - ERROR: Error while recording. Recorder stopped.
    74. ---- Quit JLink Commander ----
    75. 16:11:29 - JLink: Device "RP2040_M0_0" selected.
    76. 16:11:29 - JLink: ConfigTargetSettings() start
    77. 16:11:29 - JLink: J-Link script: ConfigTargetSettings()
    78. 16:11:29 - JLink: ConfigTargetSettings() end
    79. 16:11:29 - JLink: Found SW-DP with ID 0x0BC12477
    80. 16:11:29 - JLink: DPIDR: 0x0BC12477
    81. 16:11:29 - JLink: Scanning AP map to find all available APs
    82. 16:11:29 - JLink: AP[1]: Stopped AP scan as end of AP map has been reached
    83. 16:11:29 - JLink: AP[0]: AHB-AP (IDR: 0x04770031)
    84. 16:11:29 - JLink: Iterating through AP map to find AHB-AP to use
    85. 16:11:29 - JLink: AP[0]: Core found
    86. 16:11:29 - JLink: AP[0]: AHB-AP ROM base: 0xE00FF000
    87. 16:11:29 - JLink: CPUID register: 0x410CC601. Implementer code: 0x41 (ARM)
    88. 16:11:29 - JLink: Found Cortex-M0 r0p1, Little endian.
    89. 16:11:29 - JLink: FPUnit: 4 code (BP) slots and 0 literal slots
    90. 16:11:29 - JLink: CoreSight components:
    91. 16:11:29 - JLink: ROMTbl[0] @ E00FF000
    92. 16:11:29 - JLink: ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS
    93. 16:11:29 - JLink: ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT
    94. 16:11:29 - JLink: ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB
    95. 16:11:30 - TRACE START Event recorded.
    96. 16:11:32 - TRACE STOP Event recorded.
    97. 16:11:32 - Target stopped recording.
    Display All

  • Hello,

    Thank you for your inquiry.
    The reported behaviour is reproducible.
    We will investigate further. It is generally intended behaviour that SystemView can be used while e.g. another debug session is running.

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

  • Hello,

    OK so we were able to reproduce that SystemView does not start if you open J-Link Commander and do no target connection.
    But that is expected as the J-Link Commander in that configuration is the "main session". Now SystemView expects the main session to do all RTT init related things for the J-Link.
    However this only happens when a target connection is done.

    So if you connect to your target with J-Link Commander, let the application run with command "go" and then start SystemView, can you confirm that SystemView is working then?

    The same is the case when using GDB. Your GDB session needs to have a target connection open and the application must be running. If you then open and connect SystemView it should work.
    We tested this with the J-link GDBServer and the gcc GDB client and everything is working as expected.
    Can you confirm that this works for you as well?

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

  • Nino wrote:

    Your GDB session needs to have a target connection open and the application must be running. If you then open and connect SystemView it should work.


    We tested this with the J-link GDBServer and the gcc GDB client and everything is working as expected.
    Can you confirm that this works for you as well?
    No, this doesn't work.
    I connect and run the target via the J-link GDBServer, and while it is connected SystemView fails.
    In order to use SystemView I have to disconnect the debugger.

    This happens under both my normal dev environment (VSCode with cortex-debug) and Segger Ozone debugger.

    Nino wrote:

    So if you connect to your target with J-Link Commander, let the application run with command "go" and then start SystemView, can you confirm that SystemView is working then?
    I'll need to test this. I'll report results ASAP.

  • Nino wrote:

    So if you connect to your target with J-Link Commander, let the application run with command "go" and then start SystemView, can you confirm that SystemView is working then?
    No, that doesn't work either.
    Note that connecting Commander doesn't halt the target, but issuing 'halt' and 'go' commands doesn't change the results.


    But in these further experiments I've found that the problem is not restricted to SystemView.

    I have a terminal configured on RTT channel 0, which works fine if I connect with JLink RTT Viewer.
    While RTT Viewer is connected, I can run JLink Commander, and the Viewer terminal still works fine, whether or not I've told JLink Commander to connect.

    I can also (without involving JLink Commander) run SystemViewer while RTT Viewer is running, and use the terminal, and everything still works fine.
    Likewise I can start SystemViewer first, and then connect from RTT Viewer, and both work.
    In both these cases, if I stop whichever of the two was running first, the other reports that it has lost its connection - which I guess is because the "main session" has closed as you described.

    BUT, if I first run JLink Commander and connect to the target, and then connect from RTT Viewer, Viewer reports "RTT Viewer connected" but the terminal doesn't work, and it displays e.g. "WARNING: Sent 0 of 2 bytes" when I send a line. Quitting Commander causes Viewer to report "ERROR: Failed to read RTT data. Disconnecting".
    If I immediately reconnect Viewer, it reports "RTT Viewer connected" and the terminal works perfectly. (The target has _not_ been reset or restarted, and is alive and running throughout this process.)

    Likewise if I run JLinkGDBServer and attach from a GDB client, connecting from RTT Viewer doesn't work properly.
    If I exit the GDB Server, I can immediately connect and use RTT Viewer.

    All very frustrating.

  • Hello,

    I just gave this a try with a RP2040 and it appears that the automatic RTT search range for the RP2040 is not complete in J-Link software.
    Which is most likely the cause of the issues you are seeing and why we could not see any issues with other Cortex-M target devices.
    We will add the remaining RAM sections of the RP2040 to the automatic RTT search ranges as well. But for now you need to set the RTT Control Block address manually via SystemViews recorder settings.

    Just to make sure that we work with the same setup, could you install and use the latest J-Link software V7.54d?
    segger.com/downloads/jlink/

    Now attached you will find an example SystemView Application for the RP2040 Pico. It uses embOS and blinks the LED.
    Could you open J-Link Commander and erase your target device and program the attached hex file with command loadfile?
    Then use commands reset and go. Do you see the LED blinking?
    If yes, leave J-Link Commander open for now.

    Now open SystemView V3.30.
    Go to Target->Recorder Configuration and make sure it looks as shown in the screenshot below.
    Now start the recording.
    Do you see SystemView recording even though J-Link Commander is running?
    If, yes everything is working as expected. If no, could you provide screenshots of what you see and provide a J-Link log of the failing session?

    Now if it worked the same approach will work when using J-Link GDBServer.

    Can you confirm that this manual setting of the RTT Control block address works for your application as well?
    You can find the location of the control block in your application by searching for symbol _SEGGER_RTT in the map file.

    Alternatively you could link symbol _SEGGER_RTT into RAM between 0x20010000-0x20020000 as this is the area that is currently being autosearched.

    Regarding RTT Viewer. If you first start a Commander/GDB Server session you need to select attach mode, otherwise it will not work. But that is unrelated to the SystemView issues you are seeing.
    wiki.segger.com/J-Link_RTT_Viewer#Attach_mode

    Best regards,
    Nino
    Images

    • Capture.PNG

      10.07 kB, 644×375, viewed 397 times
    Files
    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.

  • OK, it works with your LED blinker. So evidently my software is doing something wrong - but only just wrong enough such that it works when SystemView connects exclusively.

    Here's the JLink log for my program:

    Source Code

    1. T25E4 016:466.123 SEGGER J-Link V7.54d Log File
    2. T25E4 016:500.126 DLL Compiled: Sep 28 2021 16:18:43
    3. T25E4 016:500.141 Logging started @ 2021-10-07 12:56
    4. T25E4 016:500.152 - 16500.158ms
    5. T3518 028:871.754 JLINK_RTTERMINAL_Control(Cmd = JLINKARM_RTTERMINAL_CMD_START, CtrlBlockAddr = 0x20013178)
    6. T3518 028:880.880 - 9.150ms returns 0x00
    7. T3F4C 028:895.820 CPU_ReadMem(24 bytes @ 0x20013178)
    8. T3F4C 028:896.154 Periodic RTT: RTT CB verified. Started data handling
    9. T3F4C 028:900.890 CPU_ReadMem(32 bytes @ 0x2000D620)
    10. T3F4C 028:901.948 CPU_ReadMem(32 bytes @ 0x2000D63A)
    11. T3F4C 028:902.784 CPU_ReadMem(32 bytes @ 0x2000F1B1)
    12. T3518 028:904.880 JLINK_RTTERMINAL_Control(Cmd = JLINKARM_RTTERMINAL_CMD_GETNUMBUF)
    13. T3518 028:904.906 - 0.033ms returns 0x03
    14. T3518 028:910.864 JLINK_RTTERMINAL_Control(Cmd = JLINKARM_RTTERMINAL_CMD_GETDESC)
    15. T3518 028:910.918 CPU_ReadMem(144 bytes @ 0x20013190)
    16. T3518 028:911.510 CPU_ReadMem(32 bytes @ 0x2000D620)
    17. T3518 028:912.612 CPU_ReadMem(32 bytes @ 0x2000D63A)
    18. T3518 028:913.332 CPU_ReadMem(32 bytes @ 0x2000F1B1)
    19. T3518 028:914.266 CPU_ReadMem(32 bytes @ 0x2000D620)
    20. T3518 028:915.046 - 4.200ms returns 0x00
    21. T3518 028:916.326 JLINK_RTTERMINAL_Control(Cmd = JLINKARM_RTTERMINAL_CMD_GETDESC)
    22. T3518 028:916.348 CPU_ReadMem(32 bytes @ 0x2000D63A)
    23. T3518 028:916.902 - 0.591ms returns 0x00
    24. T3518 028:941.082 JLINK_RTTERMINAL_Write(BufferIndex = 1, BufferSize = 0x00000001)
    25. T3518 028:941.120 CPU_ReadMem(24 bytes @ 0x200131F0)
    26. T3518 028:941.920 CPU_WriteMem(1 bytes @ 0x20016717)
    27. T3518 028:942.448 CPU_WriteMem(4 bytes @ 0x200131FC)
    28. T3518 028:943.100 - 2.031ms returns 1
    29. T3518 028:948.550 JLINK_RTTERMINAL_Read(BufferIndex = 1, BufferSize = 0x00002800)
    30. T3518 028:948.660 - 0.119ms returns 10240
    31. T3518 028:950.084 JLINK_RTTERMINAL_Control(Cmd = JLINKARM_RTTERMINAL_CMD_GETSTAT)
    32. T3518 028:950.102 - 0.025ms returns 0xFFFFFFFF
    33. T25E4 054:273.772 JLINK_IsOpen()
    34. T25E4 054:273.816 - 0.049ms returns 0x01
    35. T25E4 054:280.040 JLINK_Close()
    36. T25E4 054:298.284 - 18.270ms
    37. T25E4 054:298.316
    38. T25E4 054:298.328 Closed
    Display All
    So it looks like the RTT control block is being located and parsed OK, and the various buffers, labels etc located & read.

    It would appear the problem is associated with the following:
    T3518 028:948.550 JLINK_RTTERMINAL_Read(BufferIndex = 1, BufferSize = 0x00002800)
    T3518 028:948.660 - 0.119ms returns 10240
    That return value looks highly suspicious, especially compared to the corresponding return values when running the LED blinker, which are always a few hundred bytes maximum.

    I've examined all the structures in the RTT control block, and they seem valid (screenshot attached). The uplink RxOff and WrOff values suggest that the uplink data has been successfully consumed.
    Images

    • Capture.PNG

      24.14 kB, 1,206×606, viewed 385 times

  • Hello,

    It seems like there are larger data chunks in the RTT buffer with your application.
    What RTOS are you instrumenting with SystemView? Did you follow the guides as explained in the SystemView manual? Eventually the instrumentation was not applied correctly?

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

  • It depends what you mean by 'larger chunks'.
    If you mean my target instrumentation writing large chunks to the RTT buffer, then the answer is no. I'm using the standard instrumentation calls.
    If you mean the JLink probe or DLL returning larger (completely filled) buffers when being read by JLink Commander, then yes.

    But remember that this only happens (or only happens to such an extent that it prevents SystemView from working) when SystemView connects via JLink (or JLinkGdbServer).
    * When SystemView connects directly, the problem does not occur. *

    This strongly suggests that the mechanism via which JLink shares its connection with SystemView introduces timing delays that cause the buffer to fill.

    It would be very helpful if SystemView could log its API activity in the same way that JLink does for comparison, but I guess it doesn't have that capability.

    SEGGER - Nino wrote:

    What RTOS are you instrumenting with SystemView?
    I'm instrumenting a custom RTOS. It's similar in structure and complexity to FreeRTOS.
    It's instrumented with the standard SysView instrumentation API - and when connecting directly it all works great.
    (It's because SystemView is so informative that I'm so eager to get it working properly.)

    I'm about to start eliminating some types of instrumentation (e.g. task descriptions & other startup info, API calls, etc) to see if things start working at some point.

    SEGGER - Nino wrote:

    Did you follow the guides as explained in the SystemView manual?
    Yes.

    I've reviewed the manual, including the FAQ section, in particular the note regarding overflow events.
    Of course, in my case I'm not seeing normal overflow events (whichi I understand refer to overflow of the RTT buffer on the target, where SystemView pops up a notification that overflow has been detected), but in any case increasing the buffer size, ensuring the SWD frequency is at the maximum, etc, do not fix the problem.

    I notice that the final suggestion for avoiding overflow events is "Run SystemView stand-alone without a debugger".
    In my testing I'm not using a debugger - I'm simply connecting via JLink which is doing nothing (unless it's doing something under the hood).

    But as I've noted, running SystemView standalone does indeed avoid the problem.

    SEGGER - Nino wrote:

    Eventually the instrumentation was not applied correctly?
    As far as I can tell the instrumentation is fine.

  • I've removed the API instrumentation, and it now works about 80% of the time in conjunction with the debugger.
    If I need API instrumentation, I have to run without the debugger (in which case it works fine - and even supports the RTT terminal channel).
    Obviously annoying, but I'll have to live with it.