stm32g070, some custom boards start, others do not

[nielsbraspenning]

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

[TDK]

Attach a debugger, debug the code, step through it to understand where and why it's failing. Perhaps in the clock initialization.

[BarryWhit]

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.

[nielsbraspenning]

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

[Tesla DeLorean]

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.

[BarryWhit]

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.

[Tesla DeLorean]

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.

[Pavel A.]

Space station? can you share a good story? ))

 

 

[nielsbraspenning]

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

[TDK]

The most likely scenario if most boards work but some do not is there are manufacturing issues. Check resistance of PA6 to ground or VCC. Put it as input with pullup and verify it gets pulled up. Do the same with pulldown. Verify current draw from the device is as expected.

If you don't have source code, you can use STM32CubeProgrammer to run and see where the PC gets stuck, although without the program context this is harder to debug. It should at least convince you that the chip is trying to do something.

 

[nielsbraspenning]

The pin is used a output, and should enable a other piece of circuitry.

could drawing too much current from this pin also result in this issue?