This guide is meant to be car agnostic and assumes NER build system functions, such as build, debug, and flash are already known and operational. Assumes also a standard NER project on the STM32.

Crashes/stack overflow

Detecting a crash

Crashes of embedded code are common, and encompass a variety of bugs such as DMA overruns, stack overflows, heap allocation failures, undefined behavior, and more.

STM32 has what is called a HardFault Handler which is meant to catch these errors and provide a reprieve at the CPU level.

When a crash occurs:

• The CPU collects the backtrace registers

• The control unit enters the HardFault Handler

• This handler is defined in most NER projects to spam-blink the two sensor LEDS.

• After a set amount of time (usually 4 seconds) the IWDG (watchdog) will reset the core and the program will re-enter the bootup state.

In order to detect a crash, assuming the LEDs aren’t available:

• Enter the debugger/gdb

• Continue the code with c

• After 2-3 seconds, hit ctrl+c to stop the code. It should stop in the hardfaulthandler if a crash occured. If it did not, investigate other reasons for the program to hang. If you see an external reset was detected, the core was reset by the IWDG before you ctrl+c ed. Make sure you wait less than the IWDG timeout to hit ctrl+c, or the code will restart.

Debugging a crash

Follow the above steps. Once you are there in GDB, use the bt full command to see the path of the CPU before that. Find the first line from code in the repository you are using, and check it for obvious errors. This includes null pointer dereferencing and other typical C pitfalls.

CAN Comms

Understanding bit timing

Key here is you dont need to! Just use this site with st bxcan as the board type. The clock rate is usually 16 Mhz. Then copy the table into the CubeMX timing section. If the section reads the correct bitrate you want, then you are all set.