2017-08-07 03:31 AM
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:
Solved! Go to Solution.
2017-08-09 02:45 AM
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.
2017-08-07 05:11 AM
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.
2017-08-07 08:14 AM
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
>:(
2017-08-08 05:49 AM
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.
2017-08-08 09:45 AM
I guess you mean if I keep the pins for I2C and remove USART. Nice question! I will try and tell you the result!
2017-08-08 10:19 AM
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.
2017-08-09 02:45 AM
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.