cancel
Showing results for 
Search instead for 
Did you mean: 

I2C stuck when SPI enabled

Vincenzo N
Associate II
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:

0690X00000607ujQAA.png
1 ACCEPTED SOLUTION

Accepted Solutions
Vincenzo N
Associate II
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 😎 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.

0690X00000607lXQAQ.png

View solution in original post

6 REPLIES 6
Amel NASRI
ST Employee
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

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Vincenzo N
Associate II
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 

>:(

Posted on August 08, 2017 at 12:49

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

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

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!

Posted on August 08, 2017 at 17:19

No I mean SPI because the title here is 'I2C stuck when SPI enabled'. So I assume that it should be OK if SPI isn't enabled .

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Vincenzo N
Associate II
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 😎 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.

0690X00000607lXQAQ.png