EEPROM- 24FC64 -stm32g474ceux based I2C -mem-read is not working.

[mdudhat]

Hi all,

I am trying to read/write the EEPROM -24FC64 connected with stm32g474ceux microcontroller. The slave device address is 0x57 (1010 (control code)  + 111 (chip select bus) = 0x57).  I2c bus speed is 100KHz as set  during stm32CubeMX configuration.

My C code is as follows:

uint8_t Data_write = 0xAA;

HAL_I2C_Mem_Write(&hi2c1, (0x57 <<1), 0x00, 2, &Data_write, 1, 100);

HAL_Delay(10);

HAL_I2C_Mem_Read(&hi2c1, (0x57 <<1), 0x00, 2, &Data_read, 1, 100);

So during the debugging, i do not see the sent data (0xaa)  at variable Data_read pointer.

Can anyone suggest/guide me please what could be wrong here.?

Many thanks in advance.

[bmckenney]

Is there any chance WP or one of the An pins is floating? Data sheet (DS21189R) Sec 2.1 suggests there aren't any pull-ups or pull-downs on these pins.

Does HAL_I2C_Mem_Write() return an error?

[mdudhat]

Hi, @bmckenney  thanks for the Reply.

Regarding WP pin and other chip select pins A1, A2, A3 seems to be OK as its pcb based traced so. Moreover they are connected with VCC and WP pin is connected with GND. 

Actually after checking during Debugging  it shows that in HAL_I2C_Mem_Write()  function, following in if-loop returns HAL_ERROR: 

/* Send Slave Address and Memory Address */

if (I2C_RequestMemoryWrite(hi2c, DevAddress, MemAddress, MemAddSize, Timeout, tickstart) != HAL_OK)

{

/* Process Unlocked */

__HAL_UNLOCK(hi2c);

return HAL_ERROR;

}

So what can be done to remove this error.??

[bmckenney]

It looks like hi2c1.ErrorCode has some diagnostics. [Ref Github here] A NACK seems high-probability. (If WP were wrong the request would be accepted but ignored.)

If you have a scope or a logic analyzer that would be useful right about now.

For completeness: Are you fairly certain the bus pullups are OK?

[mdudhat]

@bmckenney  thanks.

yes sure . but unfortunately i can not check WP using logic analyzer as its not routed through any connector. But chip select pins A1,A2,A3 would be possible by SDA line externally.  You could have a look to attached schematic

for eeprom connection.

And one more thing in my case HAL_I2C_Mem_Read() function  written after HAL_I2C_Mem_Write() function in above code also throws an error as follows:

 

/* Init tickstart for timeout management*/

tickstart = HAL_GetTick();

if (I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BUSY, SET, I2C_TIMEOUT_BUSY, tickstart) != HAL_OK)

{

return HAL_ERROR;

}

[TDK]

Ensure HAL_I2C_IsDeviceReady returns HAL_OK before doing anything else with the I2C device.

 

[mdudhat]

@TDK  thanks.

In fact it shows HAL_ERROR after checking with HAL_I2C_IsDeviceReady () at following point:

while ((tmp1 == RESET) && (tmp2 == RESET))

{

if (Timeout != HAL_MAX_DELAY)

{

if (((HAL_GetTick() - tickstart) > Timeout) || (Timeout == 0U))

{

/* Update I2C state */

hi2c->State = HAL_I2C_STATE_READY;

/* Update I2C error code */

hi2c->ErrorCode |= HAL_I2C_ERROR_TIMEOUT;

/* Process Unlocked */

__HAL_UNLOCK(hi2c);

return HAL_ERROR;

}

}

tmp1 = __HAL_I2C_GET_FLAG(hi2c, I2C_FLAG_STOPF);

tmp2 = __HAL_I2C_GET_FLAG(hi2c, I2C_FLAG_AF);

}

[TDK]

Probably SDA and/or SCL is stuck low. This is a hardware issue. Use a logic analyzer to see what is happening on the bus. Sounds like you have one, so show the waveforms when you do a HAL_I2C_IsDeviceReady.

[mdudhat]

@TDK  thanks. Actually I checked it with HAL_I2C_IsDeviceReady() function and it does not return HAL_OK. so my following code jumps to device is not ready state. So i have to check SDA and SCL signals externally with Oscillloscope.

code view:

if (HAL_I2C_IsDeviceReady(&hi2c1, (0x57 <<1), 5, 100) == HAL_OK){

printf("No error-Device Ready");}

else{

printf("Error-Device is not Ready");

}

 

 

[bmckenney]

If you've checked WP/An then I believe you; I'm just going through the checklist. A scope/analyzer trace (SDA/SCL) shows what the bus actually sees, and so can cut through a lot of guessing, but if you don't have one that's fine.

What do you see in hi2c1.ErrorCode? The HAL clears the error flags in the device as it encounters them, but records the discoveries in ErrorCode.