STM32Cube_FW_F4_V1.8.0 I2C hardcoded timeout, why?

[Denis Krasutski]

Posted on October 20, 2015 at 11:34

Hello,

I updated ST library and got huge delay during I2C transfers when I have some errors. previously I manage timeouts in my firmware now some timeout hardcoded for example:

#define I2C_TIMEOUT_FLAG ((uint32_t)35) /* 35 ms */
#define I2C_TIMEOUT_ADDR_SLAVE ((uint32_t)10000) /* 10 s */
#define I2C_TIMEOUT_BUSY_FLAG ((uint32_t)10000) /* 10 s */

Can you explain, why ST added it? Previous library version used function argument. Do you have plans remove this? Because if I use this function whith RTOS in HI priority task when happaned error will block all system on 10sec. it is not permissible. BR, Denis Krasutski

[Nickname5522_O]

Posted on October 26, 2015 at 17:15

Hi  krasutski.denis,

I2C_TIMEOUT_ADDR_SLAVE and I2C_TIMEOUT_BUSY_FLAG are calculated as following:

(1/(minimum frequence=1Hz)) * 10 bits=10s

Which is the maximum value that can reach the timeout.

By consequence, you can change it according to your application's frequency.

''I updated ST library''

 

what do you mean by this? do you mean you updated your firmware package or you moved from SPL to HAL?

-Shahrzad-

[Tesla DeLorean]

Posted on October 26, 2015 at 17:47

As I read it, he's saying that in ~V1.8.0 you added a hard coded delay, that some prior version of same said Cube library did not.

[Tesla DeLorean]

Posted on October 26, 2015 at 18:05

I2C_TIMEOUT_BUSY_FLAG isn't in V1.3.0, use your source control tools to figure out when it was added.

STM32Cube_FW_F4_V1.3.0\Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_i2c.c

[Denis Krasutski]

Posted on October 29, 2015 at 08:26

>''I updated ST library''

 

>what do you mean by this? do you mean you updated your firmware package or you moved from SPL to HAL?

 

-Shahrzad-

 

I have changed HAL version.

>By consequence, you can change it according to your application's frequency.

 

I adhere to the concept does not edit the Thirdparty library