Home >
Creating Chaos and Hard Faults
Elecia White - Available in 3 days, 19 hours and 39 minutes (2024-05-01 12:30 EDT)
The best way to understand why the processor is sending you love letters (exceptions) is to see what they look like when you aren’t also frantically trying to fix your code. This talk goes over the code necessary to cause (and debug) divide by zero, bus errors, stack overflows, and buffer overflows.
For each one, Elecia looks at the information the Cortex-M processor provides and how to use that to determine the cause of the fault. She describes how to use the information in a hard fault handler to create small core dumps to be stored after a system reboot.
I was trying to fit this in as one last slide but I don't think I'll manage so let me reply directly. (Also, I'm plagiarizing from Ch 9 of my book.)
I have a bag of tricks I use to debug memory issues. The first is to make variables static or global to see if it is a stack issue (or an uninitialized variable issue). Note: if the problem goes away when this happens, the problem is not solved, it is hidden; you still have to fix it.
Second, you can add extra buffers between buffers (red zones). Fill these with known values (such as 0xdeadbeef or 0xA5A5A5A5). After running for a while, look in the red zone buffers to see if the data has been modified, indicating one of the buffers went outside its boundaries. You can do similar things with stacks: fill them with known data at boot and then look for how much of the stack is used after running for a significant amount of time. The highest point the stack reaches (on the edge of where the red zone data has not been modified) is called the high-water mark and represents maximal stack usage.
If you are experiencing odd issues, try making your stack(s) (or heaps) larger to see if it takes longer for the problem to occur. Alternatively, does making the stack smaller cause the issue to happen sooner? Reproducing the bug is an important part of moving from impossible bug to merely very difficult.
Finally, replace heap (malloc and new) buffers with fixed buffers. Not only can this avoid using freed memory, it alleviates issues with trying to allocate too much memory (or trying to allocate a large block when the heap is fragmented).
Hey Elecia, love your book and podcast! I know this might not be as common, but do you happen to know strategies to cause/debug dynamic memory allocation issues? Thanks so much for your time.