SystemView crash when task id == 0

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

  • SystemView crash when task id == 0

    I've generally got SystemView running but have noticed some issues that I'll document here.

    I've instrumented the SystemView firmware for a custom OS. The OS uses task IDs starting at zero so I've set SEGGER_SYSVIEW_ID_BASE to 0x00000000 and SEGGER_SYSVIEW_ID_SHIFT to 0. If I create a task with ID == 0 (i.e. create a
    SEGGER_SYSVIEW_TASKINFO struct with TaskID == 0) then the SystemView app will crash when attempting to connect to the target. If I bump the task IDs by one then it'll connect.

    Possibly related to the above, SEGGER_SYSVIEW_Warn() and SEGGER_SYSVIEW_Error() work, but SEGGER_SYSVIEW_Print() seems to cause similar connection problems as above.

    Additionally, auto-detection of the RTT Control Block when "continuous" recording (i.e. starting target then connecting with SystemView "start recording") generally works fine but auto-detection when single-shot recording (i.e. "read recorded data") does not find the block. I must specifically set the address of the block. The "target device" selected is LPC4330_M4.

    Setup:
    Eclipse Neon.3 CDT with GNU ARM Eclipse.
    OSX 10.12.5.
    JTrace Pro.
    LPC4330 target, specifically M4 in this case.
    JLink GDB Server V6.14h.
    SystemView V2.50 app and V2.50 fw.
    GNU Tools for ARM 6-2017-q1-update.

    Thanks for you help.
    -Kevin
  • A little more info from further testing:
    -If I look closely at the "continuous" capture, where the existing SEGGER_SYSVIEW_Print() _Warn() and _Error() it looks like there is sometimes gibberish data in the capture at those locations, and subsequent items in the capture sometimes don't seem to be decoded correctly.
    -If I place the SEGGER_SYSVIEW_Print() _Warn() and _Error() at different locations while doing "continuous" in the code then they may work in the new locations.
    -If I do a single-shot recording where the SEGGER_SYSVIEW_Print() _Warn() and _Error() in the original locations where it doesn't seem to be working correctly I can't get SystemView to download the data. It always says it got 0 data. However, if I export/save the raw aUp[1] capture buffer I can open the file in SystemView. The _Print() _Warn() and _Error() test messages I am printing are "Printf message", "Warn message", and "Error message" respectively. However, SystemView (and the raw data) indicates the actual text is "intf message", "Warn message", and "Error message" respectively.


    I've attached the .SVDat (with extension .bin to make the upload work) file of the single-shot capture if it helps.
    Files
    • Test.SVDat.bin

      (507 Byte, downloaded 499 times, last: )
  • Even further testing:
    -Figured out the issue with corrupted SEGGER_SYSVIEW_Print(), _Warn(), and _Error() messages: SEGGER_SYSVIEW_LOCK() and _UNLOCK() needed to be modified for custom OS.
    -Resolving the _LOCK() and _UNLOCK() issue didn't resolve the other issues mentioned.
    -Additional observation: SystemView app crashes while continuous capturing and target is stopped/halted/paused by debugger.
    -Additional observation: SystemView app causes target (running in debugger) to halt/pause, as if breakpoint hit, when "read recorded data" selected (and RTT Control Block address specified) to read completed single-shot.
    -Additional observation: SystemView app "API Functions" seem to only be recognized (via the .txt config file) if the EventId is >= 33, not 32 as indicated in the documentation.

    Summary:
    -SystemView app crash when task id == 0.
    -SystemView app crash when continuous capturing and target is stopped/halted/paused via debugger.
    -SystemView app "read recorded data" single-shot capture RTT Control Block auto-detection doesn't work.
    -SystemView app "read recorded data" single-shot capture RTT Control Block address selection works but halts/pauses target on the debugger, as if the target hit a breakpoint.
    -SystemView app "API Functions" seem to work if >= 33, not 32 as indicated in documentation.

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