cancel
Showing results for 
Search instead for 
Did you mean: 

I2C clock stretching not clearing busy bit

Santoli.Massimo
Associate II
Posted on October 31, 2016 at 20:33

HI,

I'm trying to figure our why I'm having an issue with a I2C clock stretching problem.

On my I2C bus I have various devices all work flawlessly apart from one (MCP39F521) that once you have finished a Master Transmit, it stretches the clock - SCL remains low for some time, before going back high ( see  image below ) - but the STM32 doesn't recognize the SCL going back high and leaves CR2 busy bit set... leaving the I2C bus locked...

Here an extract of the code I'm using:

MCP29F251_frame[0] = 0xA5;

MCP29F251_frame[1] = 0x08;

MCP29F251_frame[2] = MCP29F521_SET_ADDRESS_POINTER;

MCP29F251_frame[3] = ( address & 0xff00) >> 8;

MCP29F251_frame[4] = ( address & 0x00ff);

MCP29F251_frame[5] = MCP29F521_REGISTER_READ;

MCP29F251_frame[6] = 0x02;

MCP29F251_frame[7] = _calcCRC(MCP29F251_frame, 7);

if (  HAL_I2C_Master_Transmit( &hi2c, MCP29F521_address, (uint8_t *) MCP29F251_frame,8, 2000 ) == HAL_OK ){

if ( HAL_I2C_Master_Receive( &hi2c,MCP29F521_address, (uint8_t *) readBuff , 5, 2000) == HAL_OK ) {

data = readBuff[3]<<8 | readBuff[2];

return true;

}

}

The MCP39F521 received correctly the data - because I see toggling some pins that are controlled from the payload of the I2C Master Transmit - but I can't read the data coming out.

When I debug step by step the bus SR2 busy bit get cleared, if I run it normally instead I am stuck with the problem...

Any hints are welcome..

Thanks

Massimo

0690X00000605SYQAY.png

#stm32-i2c
1 REPLY 1
Santoli.Massimo
Associate II
Posted on November 01, 2016 at 22:26

Hi,

Wanted to update saying that I found a way around, following this advice:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F105RC%20I2C2%20always%20busy&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=2964

I've ended up resetting the I2C bus after the first write and then issuing the read for the result...

It's not very elegant but now it's working...

I guess the CR2 busy bit is definitely buggy in this situation..

Hope this advice helps somebody else.

Massimo