I2C SDA Pullup Causes STM32G473xx Family to Lockup

[SSpen]

I started a new project using an STM32G473CB in the QFN48 package. I've used this and other G4 chips for many other projects and never encountered this issue. This issue occurs with all 3 flash size variants (CB, CC, and CE).

I've replicated this issue using both STM32CubeIDE and CubeMX generated projects.

I have the basic project configured with PB3, PB4, PB5, and PB7 as outputs driving low current LEDs (issue occurs no matter the combination of these configured pins or connected LEDs). I'm using these just to show the processor running with the HAL_GPIO_WritePin function and HAL_Delay to create a blinky.

Everything is fine, until I solder the I2C1 pullup resistor to the SDA line assigned to PB9 (pin 47). When I do this, the program gets stuck inside of HAL_Delay. Digging deeper, the SysTick_Handler interrupt is never called, and thus the systick value remains on 0, causing the loop and the program "lockup". I have tried several resistor values, even going up to 10K to check if it's a strange power consumption issue, but no luck.

The program executes other functions correctly (it runs the initial GPIO write calls), but then hangs inside the HAL_Delay loop.

I have assembled a couple of boards, and tried multiple G473 chips on them, with the exact same result. I'm at a bit of a loss as to what could cause this. Does anyone have any ideas?

[S.Ma]

Run your code with I2C peripheral disabled to find out if it is hw or sw. Did you also put a pull up on scl? Are the pull up connected to the same vdf as the mcu ?

[SSpen]

Yep, it happens regardless of whether the I2C peripheral is configured or not, so it's more of a "pullup on PB9 causes issue" thing.

Yep, with a pullup on SCL, no problem. They are both connected right to the +3.3V supply, and the board is quite small so they are quite close to the MCU.

[waclawek.jan]

Try with a minimal blinky with loopdelay, no Cube.

> SysTick_Handler interrupt is never called

How do you know? What is the content of the systick registers? Cannot be execution stuck in some other interrupt?

JW

[SSpen]

Hmm, I'll give that a go.

I'll take a look at the registers in a moment. But going simply off breakpoints, a breakpoint placed in the IRQ handler is never called, and given SysTick is initialised before any of the other HAL config calls, it should be fired at some point.

I removed the blocking delay entirely and just had a related GPIO write call in the while(1) loop, and it was continually executed, I could pause execution and see that, and indeed the output was set correctly, but still the SysTick_Handler was never called. The systick value was always equal to 0.

[Gumer RoMa]

Hi, did you you find a solution?

I'm having the same issue with a STM32G491KE. The I2C1 SDA is assigned to PB7.

I notice if I disconnect the pull up before power on the chip and then connect it after a few seconds, HAL_Delay works as normal. I suspect the pin is messing up with the boot sequence when SDA is assigned.

[Gumer RoMa]

Update: if PB8(BOOT0) has a pull down, problem solves. I don't know why

[Bassett.David]

Hello GRodr.7,

Was Boot0 floating? Notably, you are noticing an effect from the adjacent pin, so my guess is that it was floating...

Regards,

Dave

[Gumer RoMa]

Hello Dave,

Yes, Boot0 was floating. Why does Boot0 state affect? It was booting my program.

Best regards,

Gumer