I2C communication

[Anil3]

Hello Everyone,

I am using STM32F401CBU6 controller in my project and in this project it consists of 2 I2C slaves 1) Sensor 2) EEPROM.

I2C1 is connected to slave and can able to communicate with the slave, later i have connected external EEPROM, started configuring and while configuring in CUBE IDE it is throwing warning as partly disabled conflict with I2C3 over RCC and SYS.

have checked with clock configurations everything looks fine cant able to figure it out what might causing this issue.

If i ignore and going forward means the sensor which i have connected cant able to receive the device id which is receiving in previous case.

Help me if anyone know about it.

Thank you

ANIL.

[Souhaib MAZHOUD]

Hello @Anil3 
First let me thank you for posting!

The warning "partly disabled conflict with I2C3" just inform you that some pins cannot be used over RCC and SYS when I2C3 is enabled.
You can ignore the warning and no issue will be occurred.

Thanks,

Souhaib

[Anil3]

@Souhaib MAZHOUD Thanks for your reply!!!!

The issue exactly what i am facing is that, when i am trying to write EEPROM  by using

HAL_I2C_Mem_Write(); in a following callback function HAL_UART_RxCpltCallback(); function during that time the

the write cycle delay which we usually give for writing the to EEPROM. is not coming out from HAL_Delay() function. not getting any ticks and might assuming that clock is getting corrupted so not receiving the ticks.

Thank you,

ANIL.

[Souhaib MAZHOUD]

Hello @Anil3 

Could you please provide the datasheet of the device (EEPROM) that you use in order to check if the I2C clock speed is correctly chosen in your configuration.

I will be waiting for your feedback.

Thx

Souhaib

[Bob S]

HAL_UART_RxCpltCallback() is calling HAL_Delay()?  Is that right?  Or is this HAL_Delay() in your main code after the HAL_I2C_Mem_Write() call?

The callback function runs in the interrupt context.  If the callback calls HAL_Delay() [which it really NEVER should], the SYSTICK interrupt must have a higher priority (lower priority value) than the UART interrupt.  Otherwise the SYSTICK interrupt will never be serviced and (as you see) HAL_Delay() will hang forever.

So which SYS functions are disabled or not available when you enable I2C3?  I can't tell from that screen shot you posted.

Maybe post your actual EEPROM related code along with the UART callback so we can see what is really happening.

[Anil3]

Hi @Souhaib MAZHOUD 

Here is a pic for the SCL of EEPROM.

Please find the attached.

Thank you.

[Anil3]

Hi @Bob S 

Thanks for the reply.

I am using to write to eeprom through callback function below are the pics of the way i am writing to eeprom.

[Souhaib MAZHOUD]

Hello again @Anil3 

Just let's try to change your configuration to this:

Thx

Souhaib

[Anil3]

Hi @Souhaib MAZHOUD 

I have made changes as suggested by you but still i am facing the same issue.

[Bob S · Accepted solution]

For the love of all that is good DO NOT DO THAT!!!!!!!!!!!!!!!!!!!!!

1. You call EEPROM_Write() from the UART RX interrupt/callback.  Ignoring the delay needed for the EEPROM to actually store the data, just the I2C transactions to send the data to the EEPROM take more time than you should spend in an interrupt function
2. And then you call HAL_Delay() from EEPROM_Write(), which is called from the UART interrupt/callback.  This will hang unless your SYSTICK interrupt is a higher priority than the UART interrupt - not usually the case.

Yes, you can bump the SYSTICK priority and make the HAL_Delay() call work.  But then you are delaying the UART interrupt return by 5ms times however many EEPROM pages you are writing.  And if the UART interrupt is a higher priority than other interrupts, those other interrupts can't be serviced.

Fix your code - Have the UART callback set a flag that your main code checks and then the main code performs the EEPROM updates and any other "time consuming" task (hint: declare that variable "volatile" else it won't work).