Bugs found in SystemView

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

  • Bugs found in SystemView

    We really like the idea behind SystemView and we have never seen anything comparable before. We have integrated SystemView in our own operating system running on an Atmel SAM V71 using the SAM-ICE J-Link Debugger. We know that SystemView is provided free of charge and there is no support but maybe you are interested in fixing the following bugs as they might also affect embOS. The following issues have been found in version 2.40a of SystemView (according to the release notes the bugs are not fixed in version 2.40d):

    Wrong Define
    The define "__CC_ARM__" (line 178 and 193 in "SEGGER_RTT.c" and line 270 in “SEGGER_SYSVIEW.c”) for the KEIL ARM compiler is wrong and should be "__CC_ARM".

    Reading recorded data releases CPU from halt
    The CPU will be released from halted state on pressing "Target" and "Read Recorded Data" in SystemView. The CPU has usually been halted in post-mortem mode using either the IDE or the J-Link Commander to be able to further analyze the root cause for a crash. Running the CPU on reading the recorded SystemView events makes it hard to continue with the analysis as the CPU may no longer be in the same state.

    Reading recorded data does not handle buffer wrap-around correctly
    Pressing "Target" and "Read Recorded Data" in SystemView handles the buffer wrap-around incorrectly in post-mortem mode. I have attached you the ZIP-file "WrapAround.zip" containing the buffer saved manually from the IDE before (="dump.bin", WrOff = 0xFD0) and after manual concatenation (= "dump.SVDat"). Additionally, the ZIP-file contains the buffer read automatically by SystemView in "dump_SystemView.SVDat". The wrap-around is located at address 0x1030 in “dump.SVDat” and address 0xD5F in “dump_SystemView.SVDat”. As you can see, the last byte of the buffer (= 0x08) is missing in the dump created automatically by SystemView.

    SystemView stops on synchronization bytes
    The post-mortem mode requires at least one sync in the buffer. There is usually more than one sync inside the buffer, though. It seems that SystemView will correctly use the first received sync to start decoding the events, but it stops as soon as it sees the second sync inside the buffer. This is bad especially in post-mortem mode, as the most important events are the events that have been recorded immediately before the crash. I have attached you the ZIP-file "Stop.zip" containing the buffer (="dump.SVDat") together with a screenshot from SystemView showing that 1265 events are stored in the buffer (but only the first 539 events are displayed afterwards). I have created a Python script (="SVDatDecoder.py") to decode the events stored in the SVDat file (="decoded.txt") and the first 539 events are equal to the events display in SystemView but the Python script will decode all 1265 events. The sync is decoded as NOP by the Python script and exactly at event 540 (the first event missing in SystemView), the second sync is found.

    It would be nice if you could fix some of the bugs for future releases of SystemView.
    • Stop.zip

      (43.21 kB, downloaded 183 times, last: )
    • WrapAround.zip

      (11.09 kB, downloaded 168 times, last: )
    • SYSVIEW_OSEK.txt

      (1.9 kB, downloaded 254 times, last: )

    The post was edited 2 times, last by SimonT ().

  • Hi,

    Thanks for your feedback.
    Of course our goal is to provide a working solution, so this is always welcome.

    Regarding Wrong Define:
    Sure, this will be changed in the next update.

    Regarding Reading recorded data releases CPU from halt:
    SystemView does not explicitly let the target run after reading the data, but on some devices the target state is changed when J-Link connects or disconnects.
    When there is a second connection, the target should usually stay halted, but I'll check if this applies to SAM V7, too.

    Regarding Reading recorded data does not handle buffer wrap-around correctly and SystemView stops on synchronization bytes:
    Thanks for providing the recordings and the analysis. We will check if there is an issue and will fix this.

    Best regards