How to use trace32 for bug analysis

Recently, I’ve been developing a product using the SF32LB52, but I’ve encountered an extremely strange bug: after leaving it idle for a while, the screen turns off, and pressing any button has no response. The only way to get it to reboot properly is to long-press the PA32 button for a system-level reset. When I use the serial log export function, I can’t find the problem. I need an explanation. Attached are the dump analysis screenshots.

Refer to this document: 6 Trace32 | SiFli Wiki


Look here: BLOCK_SIZE shows that the allocated byte count is clearly too large. Most likely, the problem is with rt_serial_open. The parameters passed may be incorrect—for example, the configuration structure isn’t initialized, or it wasn’t zeroed when defined, causing random values from the stack to be passed in as the requested allocation size.

Another possibility: the driver code doesn’t check the return value of rt_malloc for NULL. After allocation fails, it keeps going and writes data to an illegal address, stomping on the adjacent free-block management header. As a result, subsequent addresses are corrupted to 0x124. Under normal circumstances, the second block’s address should be right after 0x20054AF8.

Thank you for the explanation. Can we now use software to locate the problematic code, or do we have to troubleshoot the code ourselves?

Hello? Could you help answer this? This question is rather crucial.

What do you mean by “software to locate problem code”? Trace32 should already be able to locate the problem code. If you mean something like single-step debugging, then you can check out Ozone. 4 Ozone | SiFli Wiki

Are there any tutorials on using trace32 to locate problem code? Most of what’s online is about online debugging.

For tutorials on Trace, you’ll need to look at other online tutorials; the ones we currently have are: 6 Trace32 | SiFli Wiki

Very strange.

Is there a problem with the V3.1 SDK?