2025-02-21 04:06 AM - edited 2025-02-21 09:30 AM
Hi,
Here's the thing. The program is supposed to change the speed of the blinking of the user green led when you click on the blue button. I made it a week ago, tested it and all was going well. However I dropped the board this morning, four pins (2 from CN12 and 2 others from CN11) were a bit twisted but I managed to put them back (wasn't a big of a deal). I checked if there were any missing components but there weren't any. I wanted to make sure nothing was wrong so I connected the board to my computer to see (the last uploaded program to the board is the one I mentioned earlier). I was surprised by the fact that the green led was not even blinking (it is supposed to, since when powered the last uploaded program in the flash memory is supposed to be ran). So I uploaded the same program to the board again, the led was blinking but if i disconnect the board from my computer and plug it again, the led's no longer blinking. It stops blinking as well if i click on the reset button (black button on the right of the blue one). Therefore I've deduced from it that the board no longer boots from the main flash memory since the led is no longer blinking. I've looked up things like boot0 in the reference manual, I wanted to check if the pin was set to 0 but couldn't do so. I've found out about STM32CubeProgrammer a bit earlier, I used it and everything seemed fine. In the option bytes menu, nBOOT1 was checked, meaning that the board would boot from flash memory if BOOT0 = 0. This means if the BOOT0 pin is connected to ground, however before I dropped the board, there was no "jumper" connecting it to the GND pin.
2025-02-22 11:21 AM - edited 2025-02-22 11:24 AM
cn11, 12 are just gnd, removing changes nothing.
see circuit: https://www.st.com/en/evaluation-tools/nucleo-l476rg.html#cad-resources
> but the .ioc file won't let me touch them
But you show the use of HSI :
+to disable the HSE and LSE : set it unused in Cube...
btw
Maybe you damaged something - but i never heard of anybody, who managed by using a mechanical shock to delete the flash. :D
But damaging a crystal by dropping it - i did already. (Just this happened one time in my life, to be precise.)
And your board can connect st-link, flash, debug - right ? Then cpu should be 100% ok.
2025-02-22 12:06 PM
2025-02-22 01:21 PM
>by "the board can connect flash" ?
->connect st-link, flash, debug = for debug, program is flashed, from st-link. So all is working.
Maybe your program is doing something strange...
So check with STM32CubeProgrammer , what is set in option bytes , set to "normal" (default settings) , make full chip erase. Then load the program to flash (to the correct address!) and check its start address .
Maybe you set it to other address, than the "standard" start of a program, then cpu will not start it, because at the "start" address is no program...this might work in debug, because the debug starting the program, wherever it is. This could explain: program running on debug, but no more after reset. On some cpus you can even set a custom start address - i dont know L476 can do this , or not. So just check settings and read in rm.
2025-02-22 02:23 PM
Run your program in STM32CubeIDE in debug mode and see what it's doing. This a very normal part of programming. You don't have to guess what's going on.
It's probably just a code bug.
2025-02-23 08:50 AM
I did what you said, erased CPU memory then uploaded the program again. In debug mode and through disassembly, the program seems to be running from flash according to the adresses. But yeah... whenever I click on reset, no more blinking.... Thanks for your help, I'll ask my teacher once I'm back to school. I'll let you know if I find a solution.
2025-02-23 08:52 AM
I just used debug mode, program ran perfectly and did what i was expecting however I'm still facing the same issue, i.e. once I click on reset, no more blinking.
2025-02-23 09:18 AM
Modify your debug configuration not to reset or flash the chip with these two options:
and
Then, run your program until it gets into the stuck state, then attach the debugger. You'll be able to debug the current position of the code.