i am having an issue using STM32G4 with I2C DMS and FreeRTOS.
I have used the library https://github.com/firebull/STM32-LCD-HD44780-I2C for a long time with STM32F4 and free RTOS and it works perfectly.
Now I wanted to use it with STM32G4 but the Problem is:

  1. The SCL line stays low when calling:
    HAL_I2C_Master_Transmit_DMA(lcdParams.hi2c, lcdParams.address, (uint8_t*)lcdCommandBuffer, 3) and it only sends the first byte instead of 3
  2. The program get stuck in:
    while (HAL_I2C_GetState(lcdParams.hi2c) != HAL_I2C_STATE_READY) { vTaskDelay(1); }

The hardware doesn’t have any problem because I can print text without DMA using blocking mode with another driver.

I have used USB Scope to inspect the problem and tried a lot of things like resetting I2C with I2C busy flag strange behaviour or reducing the speed but nothing worked.

I have used the same configurations that worked on STM32F4 with STM32G4 in CubeMX but HAL_I2C_Master_Transmit_DMA is not sending the other bytes and the bus is held

Can someone help me please? Thanks.

update 1: I changed the 3 functions to transmit in the library from DMA to blocking mode and it works but not with DMA.

  • \$\begingroup\$ Have you tried to debug the code? For example, if the code waits for the state to be ready and waits forever, then what the state is? Busy? Error? \$\endgroup\$
    – Justme
    Jan 9, 2022 at 18:44
  • \$\begingroup\$ From your description it seems like the DMA module is not getting the trigger from the I2C module to copy the next byte to send. Are you sure you have the I2C module configured for DMA, and that you're using the correct DMA channel? \$\endgroup\$
    – brhans
    Jan 9, 2022 at 19:04
  • \$\begingroup\$ Thanks for reply, the program stucks in while (HAL_I2C_GetState(lcdParams.hi2c) != HAL_I2C_STATE_READY) { vTaskDelay(1); } because the return is HAL_I2C_STATE_BUSY_TX. but i am sure that i configured DMA correctly and as i said it sent the first byte on logic analyzer but SCL stays low and the dma does not send the second byte \$\endgroup\$
    – Majdgh
    Jan 9, 2022 at 19:32
  • \$\begingroup\$ Well to me that sounds like exactly opposite what you say about DMA being correctly configured, but as you don't show any of your code it is a bit hard to determine the issue. \$\endgroup\$
    – Justme
    Jan 9, 2022 at 19:35
  • \$\begingroup\$ should i post the main.c or what exactly do you want to see. because i even compared the old ioc file that worked with F4 and all seems the same. \$\endgroup\$
    – Majdgh
    Jan 9, 2022 at 19:38

1 Answer 1


The problem is solved!

I wanted to make a new start, so I removed the I2C1 configurations from CubeMX and generated the code to clear any old generated code related to I2C, then added I2C1 with DMS again and the problem was solved.

I think the problem was that I once changed the user label for I2C1 and then generated the code with this user label, but instead of removing the user label by removing the pins I changed the name of the pins to the label that CubeMX normally used and generated the code.

It seams that not all functionalities of HAL will work correctly with a user label, even if the name is edited to the CubeMX name. So I removed the pins and added them without changing any user label and now it works, but sadly after long hours of debugging with logic analyzer.

The conclusion is: be careful with user labels on peripherals because some HAL libraries may not work.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.