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.
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.