[SOLVED] Two bugs encountered in Real Time Terminal tools (v5.12g)

dpalchak · Jun 15th 2016, 12:21am

I recently migrated a project from using UART-based logging to using RTT-based logging. In the process, I've discovered two bugs in the RTT tools provided by Segger that make RTT unusable.

First, some details about my application. My system is based on a STM32 MCU with a Cortex-M4 core. When the MCU boots, it quickly produces a bunch of startup-related log messages and then goes to sleep. The MCU then wakes up after 500ms, produces short log message, toggles a GPIO, and returns to sleep. The sleep, wake-up, sleep cycle repeats indefinitely.

The two bugs I've encountered are as follows:

The RTT client fails to generate any output if the upload buffer fills up too quickly during the boot process. The attached file 'rtt output, sleepy=false, buffer=2048.txt' shows the output of the RTT client when the upload buffer is sized at 2048 bytes. This output is exactly what is expect during a normal boot process. In contrast, the attached file 'rtt output, sleepy=false, buffer=1024.txt' shows the RTT client output if the upload buffer size is reduced to 1024 bytes. The *only* change made to the code between the first run (successful) and the second run (failure) is reducing the 'BUFFER_SIZE_UP' value in 'SEGGER_RTT_Conf.h' from 2048 to 1024. As the file shows, the RTT client fails to produce any output for the smaller buffer size. I have confirmed that the buffer descriptor is not being corrupted when the buffer size is 1024. The buffer descriptor just sits in memory, full, waiting for the RTT client to update the read pointer. There is no reason why a buffer size of 1024 should fail to work correctly. I'm using the 'SEGGER_RTT_MODE_NO_BLOCK_TRIM' mode when writing to the buffer.
The RTT client fails to correctly read the upload buffer if the MCU returns to sleep too quickly after waking up. Again, the attached file 'rtt output, sleepy=false, buffer=2048.txt' shows the output of the RTT client when MCU is prevent from entering any low power mode (a SEV instruction is inserted before WFE). In contrast, the attached file 'rtt output, sleepy=true, buffer=2048.txt' shows the RTT client output when the MCU is mostly asleep and only wakes up periodically for only a short time. As the file shows, as soon the MCU starts its sleep-wake-sleep cycle the RTT client repeatedly outputs the same incomplete fragment of the buffer until I halt the MCU using the debugger. As soon as the MCU is halted the RTT client correctly reads and outputs the complete upload buffer. When MCU execution resumes, the RTT client again starts outputting incomplete buffer fragments.

As mentioned previously, these bugs cause the RTT tools to be unusable in my system. Perhaps more concerning is the fact that these bugs appear to be triggered by simple behaviors that are very common in embedded systems (large activity bursts and long sleep/short wake cycles). I would have expected these bugs to be caught by Segger during testing. Has Segger tested its RTT tools in real-world scenarios?

Any work-arounds or fixes for these bugs will be appreciated.

Thanks,
David Palchak

SEGGER - Johannes · Jun 15th 2016, 10:30am

Hello David,

Thank you for the detailed report.
In general it is recommended to not use sleep modes while debugging. This also applies when using RTT.

This is not a bug in RTT or J-Link, but a limitation with the sleep mode of the STM32.
In all low-power modes access to the RAM of the STM32 via the debugger is disabled.
(All reads return 0x0, writes are ignored) There is nothing J-Link can do.

For your case this means,
sometimes J-Link reads the RTT data just right when the device is woken-up,
but when the read offset is written back to the target the device is in sleep-mode again and the write is ignored.

So as written before, disable low-power modes when debugging.

Best regards
Johannes

Share