Thursday, September 21st 2017, 10:49am UTC+2

You are not logged in.

  • Login
  • Register

SimonT

Beginner

Date of registration: Dec 12th 2016

Posts: 2

1

Tuesday, February 21st 2017, 10:43am

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.
SimonT has attached the following files:
  • Stop.zip (43.21 kB - 72 times downloaded - Last download: Sep 18th 2017, 10:53pm)
  • WrapAround.zip (11.09 kB - 72 times downloaded - Last download: Sep 18th 2017, 10:53pm)
  • SYSVIEW_OSEK.txt (1.9 kB - 112 times downloaded - Last download: Yesterday, 6:16pm)

This post has been edited 2 times, last edit by "SimonT" (Feb 21st 2017, 10:44am)


SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 352

2

Wednesday, February 22nd 2017, 11:44am

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
Johannes

SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 352

3

Thursday, February 23rd 2017, 3:32pm

Hi,

The bugs in SystemView have been fixed in the new release V2.40e.
Thanks again for noticing.

Best regards
Johannes

SimonT

Beginner

Date of registration: Dec 12th 2016

Posts: 2

4

Monday, February 27th 2017, 2:33pm

Thank you very much for the very quick bugfix.