2024-08-13 07:30 AM - last edited on 2024-08-13 10:27 AM by Tesla DeLorean
Hi,
We have some problems with booting a mcu (stm32g070), we have custom hardware.
i can generate a mxcube project that works fine, every time a power the mcu on the custom hardware. this works on
all pieces which we have produced
We created a project (the purpose of the hardware) and this works fine on one example of the custom hardware
On a other piece, it seems the mcu is not starting executing code. i am not sure if it just won't start or is locked-up.
I think that something in the project is causing this, and i have bypassed basically all code. so only the init's are left and the blinking of a led
2024-08-13 08:12 AM
Attach a debugger, debug the code, step through it to understand where and why it's failing. Perhaps in the clock initialization.
2024-08-13 09:48 AM - edited 2024-08-13 09:50 AM
Might also be BOOT0 pin left floating by mistake. So random parasitics on each board decide if the board goes into bootloader or jumps to user code.
2024-08-13 10:29 AM
Get better instrumentation and determine the point of failure.
Have Error_Handler() report the line and source file that calls there to die silently.
Have a HardFault_Handler() that reports actionable data.
Use LEDs or GPIOs to signal different states, and check-points if you lack a viable serial channel to communicate outwardly with.
2024-08-13 10:59 AM - edited 2024-08-13 12:07 PM
Each person has their own approach to debugging. A very quick sanity check to see what's going on is to connect via SWD using STM32CubeProgammer and use the CPU pane see what the value of PC is. That tells you if you're in the bootloader or user code. If in user-code you can use the CubeIDE Build analyzer to see what function you're in, but then your next step is to start a debug session anyway.
2024-08-13 11:21 AM
Indeed, but most of these "Don't Run" complaints DO RUN, just not what/how is wanted.
The ability to debug and diagnose will depend a lot on what methods of communication and connectivity have been provided for.
One of the issues with STM32's is there's frequently no outward indication for signs-of-life, so you either have to create those yourself, early, and not a million instructions deep, or drop it into the ROM code, and tickle it per AN2606 and observe responses.
Might take a dozen, or two, machine instructions in Reset_Handler() to configure and set a GPIO, or squawk from a UART. Tedious to do on a custom board, when you're annoyed, for sure, but still probably easier than matching the spin on a falling space station to dock with it.
2024-08-13 11:26 AM
Space station? can you share a good story? ))
2024-08-13 12:16 PM - edited 2024-08-18 01:30 PM
> but still probably easier than matching the spin on a falling space station to dock with it.
Sure, and now that spin is increasingly AI-generated it seems even more hopeless...
2024-08-13 12:34 PM
Hi,
Thanks for the fast responses,
i have the ability to turn led's on and or put text to a terminal, however is mentioned it seem(s) the problem
happen before that point
i have a intresting conclusion, but not a solution yet.
I created a new project with only a gpio (it is connected to a led) and minimal configuration with stmcubeide, with the graphical tool (in the past it was called mxcube)
this project works and show a blinky led
from there on a copied as much settings until it has the same behiaviour as the "broken" project.
i use PA6 as output in the broken project, when i reset this to its reset state, the mcu start reliable and start executing the code.
So now i have to check why PA6 has this behaviour
2024-08-13 12:35 PM
thanks,
no this is not the case, i setup the option bytes that it ignores the pin and uses the option bytes settings.
Besides that i am able to generate a stm32mxcudeide project that works fine