Showing results for 
Search instead for 
Did you mean: 

Processor crash on PG10 initialisation

Associate III

Hi all,
I am in the process of bringing up a prototype board with a STM32L4R7ZIT6. I'm using CubeMX and use it for generating the startup code. I've configured a lot of peripherals.

When I configure PG10 as an input, the CPU crashes. Exactly at the moment that te confirmation is written in te control register of the io-port. When no other io's are configured, there is no problem. I tried to remove a lot of the peripherals, but the problem still exists. Is this a known issue? 


The geniuses at ST and Khoros seem not to understand how to implement forums dealing with their products and tool outputs. Please add a .TXT suffix to the .IOC to permit attachment.

This code fragment needs to be in early initialization

    /* VddIO2 must be enabled to access GPIO port G[2:15] */

Get a USART working, or SWV, such that your can printf() details of failures. Use a version of Error_Handler() that passes __FILE__, __LINE__ data so you can establish why/where it was called.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Yes I did




Hi Tesla,

CubeMX generated this code in the function:



 /* GPIO Ports Clock Enable */
... ...


This looks OK to me.
I inserted your code in main.c directly after the HAL Init. The result is still the same.

In a second try I attached the .ioc file as .txt. Hopefully it works now.
Regards and thanks,


Ok, but where does it "Crash" too?

Does the MCU fault, reset, drop all SWD/JTAG connectivity?

If you're able to step and or stop in the debugger where does it end up? Any dumping of registers before/after the (machine) instruction that precipitates the described failure mode?

I'm not aware of anything on the MCU side that would cause PG10 to cause product failure internally.

Sequentially the PWR clocks must be working for VDDIO2 to be enabled.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

The .ioc configures PG10 as an output, not an input as described in the OP.  Maybe attaching the CubeMX code would be helpful, along with the OP's "... configure(s) PG10 as an input".

Hi Tesla,
It appears to me that the MCU resets itself. I attached twi scope images of the nRST pin of the CPU. I also connected a GPIO output that is switched on just before the initialisation of PG10. 
The first image shows the situation without the crash (The nRST is not connected in this image) The second shows the situation with the crash. You can see that voltage of the GPIO output immediately drops. After 400 mS the CPU resets itself.

The crash occurs when the rigoster MODER is written. In this situation MODER10 is changed from '3' to '1'.



Hi David,
You are right. I noticed that with PG10 as an input, the error does not occur. So most probably I will get away with it in my project. Nevertheless this item is to interesting (for me at least) to leave unanswered.

Associate III

Problem solved.
Sorry for keeping you Buzzy. The PG10 has a capacitive coupling with the enable signal of the LDO. When the PG10 is configured as an output, it causes a smal glitch at the EN input, causing to power supply to drop for a short moment. Enough to have the CPU to restart. oeps...

Thank you all for your committment and involvement.