SPI and IIC bus not being free and locks up. Adding/removing code or changing stack size fixes the problem.

[RobG]

I have seen this with the SPI bus 6 months ago. It just just happened with the IIC bus. I am using Cube 1.12.0 and this maybe related to TKube.1 issue "Potential bug in I2C HAL layer (STM32Cube_FW_F4_V1.25.0) in I2C_MemoryTransmit_TXE_BTF() ?".

I have an array[6][3]. If I initialize the first 5(x3) entries in a routine that is not run the code runs as expected under the debugger. If I initialize all 6 (X3) entries the code hangs in in I2CDevice::MemReceive waiting for the bus to be free the first time I try to read a memory. If I replicate the 6th initialization 5 more times the code runs as expected. If I go back to the non working code and increase the stack from 0x2000 to ox2004 it runs as expected. This was repeatable as I showed it to a colleague. When I was seeing the SPI problem if I cycle power (and the code ran from power up) it functions as expected despite just locking up under the debugger.

Stack analysis says I was using less then half the allocated stack.

I was about to try a software reset of the IIC bus to see if that would free it up, but apparently I changed something another file and everything is working as expected.

I feel like I am missing something, but 30 years of experience is telling me this is a debugger issue and not my code. Anyone seen similar or have any thoughts?

Thanks

Rob

[TDK]

How can an SPI bus not be free? Master can toggle SCK and CS at any time, slave only listens.

Put a logic analyzer on the lines so you see the issue clearly.

[RobG]

The SPI bus was 6 months ago. You maybe correct that it was free. Rethinking I think it just continually threw an error because HAL_SPI_TransmitReceive did not return OK. But look at the fix adding code, removing code, or changing stack size caused it to work. So the code is correct (maybe), but something happens during compilation or debug. I lean toward debug since a reset and the code ran correctly.

If I am correct that I have plenty of RAM, ROM and stack. How can changing the code in an unrelated section of code (that isn't even run in normal operation) change the behavior?

[Piranha]

SPI bus being free doesn't mean the broken HAL driver knows that. Could be related to this:

https://community.st.com/s/question/0D50X0000C5Tns8SQC/bug-stm32-hal-driver-lock-mechanism-is-not-interrupt-safe

Anyway, all of the described issues are exactly the way a broken software manifests itself. I don't know your code, but ST's code is an absolute junk - broken by design and implemented as a bloatware full of bugs. Broken logic, race conditions, no interrupt/thread safety, missing volatile qualifiers, missing memory and compiler barriers - HAL/Cube code is full of those and other issues. With 30 years of experience one should see it by just looking at code for 15 minutes.