Background
I am working on a school project where I have designed a prototype PCB with the core being a STM32F042K6T6 microcontroller. I am using the ST-Link from a Nucleo STM32F401RE card to program it.
Problem
When programming the device with some simple code to light an LED, the LED wouldn't light up. While troubleshooting, I accidentally realized that the LED would light up after a fresh "power on" (without changing code or reprogramming the MCU), simply pulling the power supply and then reconnecting it.
This lead me to believe something was wrong with the reseting of the device after the programming. To test this I started from a shining LED after power-on, and then pressing the reset button for a hardware reset. As suspected the LED would go dark and then not light up again. Then when I disconnect the power and reconnect it again it lights up.
Further observations I reckon might get asked.
- The voltage levels of the device seems good, decoupling is placed according to data sheet.
- Reset is implemented with external pull up with a 10k resistor to 3.3V and then a button for shorting to ground on reset and a parallel cap of 100 nF down to ground. (This is connected to the NRST pin on the MCU as well as the NRST pin on the programming connector).
- The LED is a simple SMD led with a 180 ohms series resistance put on GPIO PB5. (Actually have 3 different status LEDs on the board, and can start them all in code
I have probed the "analog" signal of the reset pin, and to me the signal seems fine, dropping low when I click/hold the reset button. And as the LED turns off when clicking the reset button, I believe it starts to restart the program. However it doesn't seem to fully reinitialize and start executing code from the start of 'main()`? As the code actually works to light the LED after a power-on reset. Therefore the correct instructions seems to have been uploaded to the program memory, but the resets (both while programming and on clicking the reset button) seems to somehow fail to reinitialize the .
Any assistance would be greatly appreciated.
Best Answer
My bet is on boot0; Check that you've got it pulled low.
The boot0 pin selects where the MCU will start executing code from when it boots up, ie. comes out of reset. If boot0 is low, it'll execute your code from flash, but if it's high, it'll execute the internal bootloader from the system memory.
My guess is that you have left boot0 floating, and when you're doing a cold boot (ie. disconnecting and reconnecting power), it'll be close to zero, so the MCU will boot your code from flash, but when you do a warm boot with the reset signal, the pin will have floated to a higher value, is read as high, and the MCU will boot to the internal bootloader from system memory instead of your code.
This explanation assumes you haven't touched the boot-related option bytes, which would change the behaviour. Also, in case you'll be working with different STM32 MCUs at some point, please note that they can have slightly different behaviour. Some have different boot-related option bytes. All I've seen so far have had a boot0 pin which behaves identically, but some also have a boot1 pin (which might be shared with a gpio pin) that you might also have to set correctly. In the MCUs I remember seeing, though, boot1 is only relevant if you want to be able to boot from system memory or SRAM.