Post-mortem mode recording

While single-shot recording supports analyzing runtime behaviour analysis from a defined starting point until the SystemView buffer is filled with events, Post-Mortem Mode displays the latest system activity when reading out the data.

Both modes are useful for different purposes.

Post-mortem mode can be useful to verify an embedded system's behavior prior to a sudden crash or in long time tests when verifying the behavior before specific events after running for several hours.

Single-shot recording can be used to record the startup of a system and to verify, that a specific part of the system behaves as expected, e.g. that an interrupt triggers the correct task activation.

System Crashes: When an embedded system using of SystemView’s post-mortem mode crashes, the SystemView recording can provide important information about the system’s runtime behaviour and what might have caused the crash.

This information may help to directly identify the problem or to create a reproduction scenario for further analysis.

Example scenario: A house-control system, controlling the heating system and connected to the internet, receives commands from a control server. The commands are handled by the controller task. The house-control works well, but some units crash occasionally. When debugging the system the crash does not occur. There is no hint what might go wrong.
SystemView’s post-mortem mode can help in this case and provide information about what happened prior to the crash, i.e. which task was running and crashed.
The SystemView module is included in the application and configured for post-mortem mode. The system can be used as usual.

After the system has crashed, a J-Link is attached to the system. With the J-Link the target is halted and the SystemView buffer read from the target into a file.
Analyzing the recording with SystemView shows that the last activity was  in the monitoring task, which handles sensor data.

Going back in time displays the last system activity flow. The controller task received a command to power down the heating system. While the controller task was active a timer interrupt triggered the monitoring task which pre-empts the controller task and tries to read the sensor data.

A closer look at the source code reveals that accessing the sensor can cause a crash when the heating system has been powered down. The problem could be solved by locking access with a resource semaphore.

SystemView’s post-mortem mode does not only help to analyse system crashes. It also can be used to analyse apparently fine running systems, i.e. to verify that a system behaves as expected after free running for a longer period of time.

Analysis of free running systems might reveal issues in the embedded system, like time differences or memory leaks, which cannot be found when debugging the system for a short period of time but might affect released products.

Example scenario: A System displays an inaccurate run time.

In long time tests, after running for several hours, the time was off by 1 minute, compared to an external stopwatch.
Normal debugging of the system does not show any issue. The system time is retrieved and displayed correctly. The issue seems to occur only when the system is running for a longer period.

Running an embedded system with a debugger connected can influence the system behaviour. SystemView’s post-mortem mode can help in such cases. The SystemView module is included in the application and configured for post-mortem mode. Now the system is left running stand-alone.

In a new long time test, when the wrong time is displayed, a J-Link is attached to the system. With the J-Link, the target is halted and the SystemView buffer read from the target into a file.

Loading the saved file into the SystemView App reveals that a timer interrupt handler sometimes runs for more than one millisecond and a SysTick interrupt gets lost, which results in the system time to become incorrect.

NOTE: Post-mortem analysis requires the debugger or debug probe to be able to connect to the target system without resetting it or modifying the RAM.

To get as much useful data for analysis as possible it is recommended to use a large buffer for SystemView, 8 kByte or more. External RAM can be used for the SystemView buffer.

To configure the target system for post-mortem mode, the following configuration needs to be done: Define SEGGER_SYSVIEW_POST_MORTEM_MODE as 1

Define SEGGER_SYSVIEW_SYNC_PERIOD_SHIFT to make sure at least 1 sync is in the buffer.

Recommended sync frequency: Buffer size / 16. I.e. 4 kByte buffer = Sync every 256 packets = SEGGER_SYSVIEW_SYNC_PERIOD_SHIFT as 8.

To start recording in the system call SEGGER_SYSVIEW_Start(), i.e. in main() after calling SEGGER_SYSVIEW_Conf().
For more information refer to chapter "Target configuration" of the SystemView User Manual.

Without a J-Link or without the SystemView App the data can be read by following the steps below. Since the SystemView buffer is a ring buffer, the data might have to be read in two chunks starting at the beginning and save as much data as possible:

• When the system crashed or all tests are done, attach with a debugger to the system and halt it.
• Get the SystemView RTT buffer (Usually _SEGGER_RTT.aUp[1].pBuffer).
• Save the data from pBuffer + WrOff until the end of the buffer to a file.
• Append the data from pBuffer until pBuffer + RdOff - 1 to the file.
• Save the file as *.SVdat or *.bin.
• Open the file with SystemView.