possible bug in HAL_I2C_Mem_Read_IT and HAL_I2C_Mem_Read_DMA?

[noobee]

Posted on April 06, 2015 at 06:36

hey all

trying to get basic interrupt-based and DMA-based I2C code to run. the setup is a stm32f103cb with mpu6050 connected via I2C. i followed the HAL I2C examples except that there are none specifically for

HAL_I2C_Mem_Read_IT

and

HAL_I2C_Mem_Read_DMA

(not even on the public internet). in any case, i got it mostly working except if i tried to transfer a single byte from the device. the following call fails.

HAL_I2C_Mem_Read_IT(&hi2c2,
(uint16_t) MPU6050_ADDRESS,
(uint16_t) MPU_RA_WHO_AM_I,
I2C_MEMADD_SIZE_8BIT,
(uint8_t *) buf,
1);

but, the following call works:

HAL_I2C_Mem_Read_IT(&hi2c2,
(uint16_t) MPU6050_ADDRESS,
(uint16_t) MPU_RA_WHO_AM_I,
I2C_MEMADD_SIZE_8BIT,
(uint8_t *) buf,
6);

the only difference is the size of the transfer (1 byte fails, 6 byte works). i also tried

HAL_I2C_Mem_Write_IT

, which seems to be working for 1 byte writes. i have not tried

HAL_I2C_Mem_Write_DMA

. the failure mode in both cases seem to be related to timing out waiting for the I2C controller to be not BUSY. so, does any one have a working example or theory what's wrong? is there a bug filing process for ST? so far, i found 3 issues with the stm32cubeHAL in 2 days (the other one is related to remapping JTAG pins for GPIO, the generated code does not work), making me a little nervous and wonder if i should stick to SPL instead...

[Amel NASRI]

Posted on April 06, 2015 at 11:14Hi Noobee,Will go back to you on this topic regarding I2C data transfer issue.But could you please provide us more details on the second faced issue related to GPIOs?Thanks-Mayla-

[noobee]

Posted on April 06, 2015 at 14:05

thanks for the quick response!

i reported the other issue here: [DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/stm32cube%20not%20calling%20%20%20__HAL_AFIO_REMAP_SWJ_NOJTAG%28%29%20in%20the%20right%20order&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/AllItems.aspx&currentviews=8]stm32cube not calling __HAL_AFIO_REMAP_SWJ_NOJTAG() in the right order?basically, i think the call to 

__HAL_AFIO_REMAP_SWJ_NOJTAG

() 

in the generated code is too early and should be done later, after calling 

__HAL_RCC_AFIO_CLK_ENABLE().

moving it manually seems to fix the issue.thanks.

[stst9193]

Posted on April 12, 2015 at 09:09

>> the failure mode in both cases seem to be related to timing out waiting for the I2C controller to be not BUSY.

Which version of the HAL are you using. This may be solved in the latest version (march 2015 - or even in the Dec 2014). Gerard

[MAI THANH.Brice]

Posted on August 01, 2016 at 09:01

Hi

I search on the forum and this is the only topic where this problem has been discussed but no solution was proposed. Do you have more information on this problem ? The following screenshots show a 1 byte and 2 bytes data read. The ''Led'' signal is set before the read and clear in ''HAL_I2C_MemRxCpltCallback''When I read only 1 byte, the clock stays low at the end and the I2C flag is still busy. This problem doesn't appears when I read 2 or more bytes.I2C version is :  * @file    stm32f4xx_hal_i2c.h  * @author  MCD Application Team  * @version V1.5.0  * @date    06-May-2016

[MAI THANH.Brice]

Posted on August 01, 2016 at 13:40

Hi

I continued to monitor the I2C driver and found something strange. On the following screen, the signal ?IT EVT? is a GPIO that is toggle every time I enter ?I2C1_EV_IRQHandler()?I found strange to enter this often after the address so I monitor the different IT flag and add them on the screenshot.Hope you could help and fix this problem