2019-12-10 04:26 PM
The HAL_I2C_Transmit_IT() in the STM32H7 HAL respond incorrectly, when the I2C bus returns NAK.
In case of NAK, the I2C error interrupt must be triggered immediately, but it is triggered few seconds later. This is wrong response.
The attached zip file contains a demonstration project for the Nucleo H743ZI. Once you run, you will see the Start message, and then error message. While the error message have to be displayed immediately, you have to wait several second.
Note : You must pull up the I2C1 bus (PB8, PB9) correctly, and must not connect device on the I2C address 0x00.
I have tested this program with following environment.
Please check.
2019-12-11 02:18 AM
Hello @Takemasa
We need more details on the issue you faced? Which CubeH7 are you used ?
Is it related to this issue I2C NACK problem ?
Best Regards,
Imen
2019-12-11 02:57 PM
Hi @Imen DAHMEN
The Cube H7 is v1.5 as you can see in the screenshot.
The linked I2C NACK problem is slave. But this one is master. It looks like different.
Takemasa
2019-12-21 04:07 PM
Any update?
2020-01-03 02:53 AM
Hello @Takemasa ,
We have not been able to reproduce your use case in the application with STM32CubeH7 fimware package.
When the problem occurs ? Please try to debug and localize where the code hangs/stop,
Best Regards,
Imen
2020-01-12 07:56 PM
Hi @Imen DAHMEN ,
I am surprised you could not reproduce this problem.
I have tested again with same setting with my original settings.
I am afraid you misunderstood how to identify the success / failure of I2C by this demo soft.
On my Nucleo H743ZI board, this program displays "I2C ERROR" message several seconds after the "I2C TX start" message ( See screenshot ). This is wrong behavior.
Please check.
2020-02-10 11:53 PM
Hi Imen
Any update on this issue?
2020-02-12 08:25 AM
Hello @Takemasa ,
Sorry for the delay to answer you.
I tested your attached code using the Nucleo-H743ZI with STM32CubeH7 V1.5.0 and I reproduced the same issue : "I2C ERROR" message appears afer several seconds.
This issue is under investigation. I will come back to you soon with update.
Thank you for your understanding.
Best Regards,
Imen
2020-03-07 03:43 PM
Hi @Imen DAHMEN ,
I believe I found the root cause. The default IO drive configuration by CubeIDE is too weak. Please see attached screenshot. Those are the default configuration of the Nucleo F722ZE and Nucleo H743ZI.
You can see the maximum output speed. While F722ZE is very high, the H743ZI is low. I changed this configuration while low to high. So problem is disappeared. I am not sure what is the appropriate value. Anyway, the "low" configuration seems to be not appropriate.
I strongly recommend you to change the default Maximum output speed.
By the way, the F722 pins are configured as "pull-up". I found a good report to recommend not-to-pull-up internally :
https://github.com/ARMmbed/mbed-os/issues/5102
Regards,
Takemasa
2020-03-08 01:09 PM
@Imen DAHMEN And the same question about UARTs configuration for H7.
The Cube generates LOW speed at least for some UARTs. Should it be high too?
Some replies here suggested that speed setting for Alternate Function pins is not effective at all?
-- pa