Erase Buggy MCU firmware¶

If you start the debugger or flash the MCU and nothing happens because the MCU jumps to the Reset_Handler() function or hangs on an operation, your implementation has a serious bug. If you still have an active connection via JTAG, you can debug and reflash the firmware. But what if the connection is lost due to a configuration error that disconnects the JTAG lines? In such a situation, neither reset nor unplug and replug will solve the problem. This is because the faulty firmware is automatically loaded after a reset or on power-up. To overcome this problem, the faulty firmware must be erased so that the MCU can boot with its default configuration. The key question is how to erase the buggy firmware from the on-chip flash. The video below shows an example of this behaviour.

Demo

Erase the firmware¶

To remove the faulty firmware, follow the step-by-step instructions and read the explanations carefully.

Stop the debug mode

Exit the Debug menu to avoid loading a new session the next time.

Hint

Reset buttons locations¶
Unplug and replug

Unplug the USB cable that connects the ST-Link and plug it back into your computer.
Reset the MCU
1. Press and hold the reset button on the MCU (B2) or on the mbed application shield (RESET) until you have completed this step.
  
  Hint
  
  Reset buttons locations¶
2. Run make with the target “reset” in the Makefile as follows.
```
make reset
```
3. Wait for the process to complete. You will see a message similar to the one below.
```
ERROR common.c: Soft reset failed: timeout
INFO common.c: F446: 128 KiB SRAM, 0 KiB flash in at least 128 KiB pages.
```
4. After completion, release the reset button.
Demo
Erase the MCU’s on-chip flash memory

To erase the on-chip flash memory that contains the erroneous program, use the erase target in the Makefile. After executing this command, the MCU will boot with the default values of the registers. This will enable the JTAG interface and you will be able to access it from the debugger.
```
make erase
```
Demo

Danger

Debug the faulty firmware before reflashing! How to do this is explained in more detail in the Troubleshooting and fixing section.

Debugging¶

If you reload your program with the bug, you will be right back in the same situation. There are two ways to debug your implementation, but first look at your implementation and look for errors in the bit manipulation. If you have not found an error, try the following methods.

Breakpoints¶

This is the easier way to solve the problem. Set a breakpoint at the beginning of the main() function and step through the program. If your program hangs at a certain point, or if it pauses at the same point, then this is probably where your bug is located. If it is on a line where a function is called, use the step in functionality and continue debugging there.

Warning

While our compiler optimises your implementation, you cannot be sure that every line you write will be processed exactly as you wrote it. This will show up as an error right at the beginning. Use the second option for this.

Note

If the debugger stops at a brake point and there is no code reference. The compiler has probably optimised it. For debugging purposes it is sometimes helpful to disable code optimisation. Check the compiler option in the Makefile and change it accordingly.

Comment out Code¶

If the first method fails, comment out the lines that you are not sure are doing the right thing. Next, uncomment your implementation one line at a time, and test it right up until the error occurs. This is probably where your error is.

Tip

To avoid a lot of debugging, test your implementation continuously.