Skip to main content
Heinrich
Associate III
November 1, 2022
Solved

STM32G431KBTx (Nucleo-32 board), UART and I2C EEPROM makes problems

  • November 1, 2022
  • 4 replies
  • 2597 views

Hello together,

I'm using Nucleo-32 board (with a STM32G431KBTx) and have got some problems...

In my project I'm using:

-> UART (here I'm using RX-DMA and interrupt with an IDLE-flag)

-> ADC, one channel

-> I²C with an EEPROM (no DMA, no Interrupt)

Problems and attempted solutions

Problem 1: if I write some bytes to EEPROM (I'm using HAL_I2C_Mem_Write(...) for that), and wait 5ms after the writing a page, the MCU stucks in HAL_Delay forever. After some googling I found a solution for this, increase interrupt priority for SysTick_Handler. Okay, all my interrupts have 0 as "preemption priority", so I've configured priorities like this:

0693W00000VOcyGQAT.pngAfter that fix, reading/writing from/to EEPROM runs like a charm.

BUT:

The uart communication broke. That means, I request some data (exactly 70 Bytes) from MCU by sending a character (i.e. an V), but I get just 65 bytes, or 67 bytes, or 70 bytes, or 64 bytes... so it's not deterministic, but in 98% the requests I get less then 70bytes...

If I set all the priorities to 0, the uart communication is fine, but HAL_Delay stuck...

Any ideas? I've attached the whole project (STM32CubeIDE 1.10.1)

Thank you very much & kind regards,

Heinrich

This topic has been closed for replies.
Best answer by MM..1

Primary dont use haldelay in interrupt routines.NEVER

4 replies

MM..1
MM..1Best answer
Chief III
November 1, 2022

Primary dont use haldelay in interrupt routines.NEVER

Heinrich
HeinrichAuthor
Associate III
November 1, 2022

I'm using HAL_Delay in a function, which is called from interrupt routine, after clearing the IDLE flag.

Regards,

Heinrich

gbm
Lead III
November 1, 2022

And that's exactly what you should NOT do.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice
Heinrich
HeinrichAuthor
Associate III
November 1, 2022

Okay, my mistake...

After I reimplemented the UART stuff, I²C seems to run fine.

Thank you guys!