Random writes in RTT control structure

dcihlar · Jun 20th 2017, 4:08pm

Hello!

We're having some issues with RTT - it occasionally stops, but the application continues to work. It looks like RdOff is sometimes set to an out of range or random number. After it is set manually to the same value as WrOff, RTT comes to life again.

I've set data breakpoint to it and it never halts the CPU, so it must be something on the J-Link/PC side.

While debugging, I've also noticed that sometimes other fields are changed as well, but luckily, to the same value as it was before. Except for sName. I've seen it once become a random pointer.

My coworker has the same problem, but his RdOff gets always stuck on 1024 with buffer size of 1204 bytes. Mine RdOff gets stuck with numbers within 0x3FF0xxxx regardless of the buffer size.

The same happens both with Ozone and gdb on Linux. JLinkExe reports following versions:
SEGGER J-Link Commander V6.16a (Compiled Jun 6 2017 12:46:48)
DLL version V6.16a, compiled Jun 6 2017 12:46:35
Firmware: J-Link V9 compiled Jun 9 2017 17:27:29

The device used is STM32L433CC.

SEGGER - Niklas · Jun 20th 2017, 5:24pm

Hi,

thanks for your inquiry.
Are you using any low-power modes in the target application?
If yes, could you please give it a try if these issues occur when not using any low power modes?

Best regards,
Niklas

dcihlar · Jun 20th 2017, 5:29pm

Hi,
thanks for the quick reply.

No, low power modes are not used.

SEGGER - Niklas · Jun 20th 2017, 5:33pm

Hi,

would it be possible for you to provide us with a project / binary file which can be used for reproduction ?

Best regards,
Niklas

dcihlar · Jun 20th 2017, 5:46pm

Unfortunately, we can't send you the whole project, but we could try to create a small one that has the same problem.

But before that, can we somehow confirm that we aren't having problems with the programming cable? We are now suspicious of it because gdb and Ozone both have some stability issues. JLinkGDBServer sometimes dumps a bunch of errors of how it couldn't access CPU registers in running state, and Ozone just displays an error that it can't read device status.

Maybe the same cause produces problems on debugging tools and RTT.

SEGGER - Alex · Jul 28th 2017, 1:09pm

Hi,

a stripped down project would certainly help.

But before that, can we somehow confirm that we aren't having problems with the programming cable?

Trying another cable?

We are now suspicious of it because gdb and Ozone both have some stability issues. JLinkGDBServer sometimes dumps a bunch of errors of how it couldn't access CPU registers in running state, and Ozone just displays an error that it can't read device status.

That indeed sounds like HW issues or evil software that disables the debug signals and reconfigures them to GPIO temporarily or disables clocks for certain peripherals so certain memory is no longer accessible etc.
Maybe trying another cable first is a good idea.
Then check if the stability problems remain.

Also check on an eval board in parallel, to make sure that there is no issue on your HW (connector not soldered correctly etc.).

Best regards
Alex

Share