cancel
Showing results for 
Search instead for 
Did you mean: 

I2C Slave hanging after 30-45 minutes of correct operation

whatsintheBOX
Associate

Hi,

I have a STM32F103C8T6 configured to operate as an I2C slave device on I2C1. It operates as intended for 30-45 minutes before the I2C hangs indefinitely with a HAL I2C state code of 0x2A = HAL_I2C_STATE_BUSY_RX_LISTEN. In this state, further I2C transmissions won't occur but the main code loop will continue to execute without issue.

I've tried restarting and resetting the I2C with the inbuilt HAL commands when in this state without success. However, whilst probing with a STLINK debugger to observe the code, merely adding a break point once the I2C is hanging (even if the break point is in a section of code that won't be triggered) will fix the issue immediately.

Any pointers or ideas for fixing it would be greatly appreciated, the non-HAL I2C slave functions I used are below:

 

extern I2C_HandleTypeDef hi2c1;

 

uint8_t rxData[8] = {0, 0, 0, 0, 0, 0, 0, 0};

uint8_t txData[8] = {0, 0, 0, 0, 0, 0, 0, 0};

uint8_t newData = 0;

uint8_t rxCount = 0;

uint8_t txCount = 0;

 

void HAL_I2C_ListenCpltCallback(I2C_HandleTypeDef *hi2c){

HAL_I2C_EnableListen_IT(&hi2c1);

}

 

 

void HAL_I2C_AddrCallback(I2C_HandleTypeDef *hi2c, uint8_t TransferDirection, uint16_t AddrMatchCode){

// See if I2C transactions are still operating

HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);

if(TransferDirection == I2C_DIRECTION_TRANSMIT){

// Reset transfer counter

rxCount = 0;

// Receive first byte

HAL_I2C_Slave_Sequential_Receive_IT(hi2c, rxData+rxCount, 1, I2C_FIRST_FRAME);

}

else{

// Send first byte

txCount = 0;

HAL_I2C_Slave_Seq_Transmit_IT(hi2c, txData+txCount, 1, I2C_FIRST_FRAME);

}

}

 

void HAL_I2C_SlaveTxCpltCallback(I2C_HandleTypeDef *hi2c){

// Transmit following bytes of data after 1st

txCount++;

HAL_I2C_Slave_Seq_Transmit_IT(hi2c, txData+txCount, 1, I2C_NEXT_FRAME);

}

 

void HAL_I2C_SlaveRxCpltCallback(I2C_HandleTypeDef *hi2c){

// Receive following bytes of data after 1st

rxCount++;

newData = 1;

// If isn't full

if (rxCount < RxSIZE){

if (rxCount == RxSIZE-1){

// Store last byte

HAL_I2C_Slave_Seq_Receive_IT(&hi2c1, rxData+rxCount, 1, I2C_LAST_FRAME);

}

else{

// Store next byte

HAL_I2C_Slave_Seq_Receive_IT(&hi2c1, rxData+rxCount, 1, I2C_NEXT_FRAME);

}

}

if (rxCount == RxSIZE){

// Data is now stored

}

}

 

void HAL_I2C_ErrorCallback(I2C_HandleTypeDef *hi2c){

// Error handler

uint32_t errorcode = HAL_I2C_GetError(hi2c);

if (errorcode == 4){

// AF Error, data is less than maximum bytes, ignore error

__HAL_I2C_CLEAR_FLAG(hi2c, I2C_FLAG_AF);

if (txCount != 0){

txCount = txCount -1;

}

}

// Re-enable interrupts

HAL_I2C_EnableListen_IT(hi2c);

}

 

1 ACCEPTED SOLUTION

Accepted Solutions
whatsintheBOX
Associate

For anyone interested / having the same issue in the future - it seems to be an issue with this MCU specifically, maybe the STM32F1xx series.

Testing on a STM32F413ZH, STM32WB55RG, STM32L4R5ZI and STM32H7A3ZIQ Nucleo development boards - none had this I2C issue in over 48 hours of testing on each board using the same code.

View solution in original post

1 REPLY 1
whatsintheBOX
Associate

For anyone interested / having the same issue in the future - it seems to be an issue with this MCU specifically, maybe the STM32F1xx series.

Testing on a STM32F413ZH, STM32WB55RG, STM32L4R5ZI and STM32H7A3ZIQ Nucleo development boards - none had this I2C issue in over 48 hours of testing on each board using the same code.