2016-10-31 12:33 PM
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..ThanksMassimo #stm32-i2c2016-11-01 02:26 PM
Hi,
Wanted to update saying that I found a way around, following this advice: 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