I2C stuck when SPI enabled

[Vincenzo N]

Posted on August 07, 2017 at 12:31

Hello, I have the following problem:

I have a I2C communication routine that takes about 2ms to be executed.

After I do the first read/write operation on a SPI peripheral, the same routine takes250ms the first time, than it stops working becaus isDeviceBusy always fails.

If I call __HAL_SPI_DISABLE(&hspi) after using SPI, the I2C routine starts working again as before (takes 2ms again and isDeviceBusy does not fail).

So, summarizing:

init_all()
i2c_routine() // Takes 2ms
spi_routine() // 
i2c_routine() // Takes 250ms
i2c_routine() // Stucks�?�?�?�?�?�?�?�?�?�?
init_all()
i2c_routine() // Takes 2ms
i2c_routine() // Takes 2ms
i2c_routine() // Takes 2ms
i2c_routine() // Takes 2ms�?�?�?�?�?
init_all()
i2c_routine() // Takes 2ms
spi_routine() 
__HAL_SPI_DISABLE(&hspi)
i2c_routine() // Takes 2ms
i2c_routine() // Takes 2ms�?�?�?�?�?�?�?�?

It seems to be a weird behaviour to me. I've tried a lot of things in the last 2 days, but I cannot understand the cause. May somebody more experienced tell me what's going on? Thank you!

The device isthe STM32 Nucleo for L4 series (STM32L432KCU6). I'm using STM32CubeMX and System Workbench for Stm

I also attach the pin configuration:

[Amel NASRI]

Posted on August 07, 2017 at 14:11

Hi

vnap12

‌,

1- Try to reduce your code and your configuration to reproduce the issue.

2- check if I2C is working on standalone as well as SPI

3- provide details about I2C and SPI routines used in your code

-Amel

[Vincenzo N]

Posted on August 07, 2017 at 17:14

Thank you.

I disabled USART1 and used PA9/10 for I2C, now the problem isn't there anymore.

That does not explain the cause though 

>:(

[Amel NASRI]

Posted on August 08, 2017 at 12:49

If you keep PB6/PB7 for I2C and remove SPI, does it work?

-Amel

[Vincenzo N]

Posted on August 08, 2017 at 16:45

I guess you mean if I keep the pins for I2C and remove USART. Nice question! I will try and tell you the result!

[Vincenzo N]

Posted on August 09, 2017 at 11:45

I think that it could be something related to the configuration of solder bridges SB16 and SB18. In their default state (on) they do not allow using PA5 and PA6 on their assigned pins (CN4 7 and 8) but they connect the pins directly to PB6 and PB7.

I think that's why, in the original pin configuration, what happened on SPI pins influenced I2C communication: because the pins where connected each other.