cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F091RCTx SPI send issue

LSant
Associate

I'm using STM32CubeMX v4.25.0 to generate the HAL files for SPI2 and Attolic TrueSTUDIO to compile/debug my application. My intent is to communicate with external flash. Sending/receiving commands with "HAL_SPI_TransmitReceive_IT", everything works fine. But at this moment I'm trying to improve the funcnality of my driver, using the functions "HAL_SPI_Transmit_IT" and "HAL_SPI_Receive_IT", wich bring me a full control of the comunication (in my case!!!). 

So, using "HAL_SPI_Transmit_IT", the handle var "hspi2->lock" doesn't change to "UNLOCKED" after sending all bytes. My callback function "HAL_SPI_TxCpltCallback" is called after sending all data but, this var still "LOCKED".

In the file stm32f0xx_hal_spi.c, line 1312, you'll find the following instructions that one is responsible to unlock the spi:

"

error :

 __HAL_UNLOCK(hspi);

 return errorcode;

"

Explaining a little bit more my debug.

Situation1:

1. I've put a breakpoint on "__HAL_UNLOCK(hspi);" line and in the first command of my callback function;

2. Run the application from the beginning, which send a simple command after 1s running;

3. When the application stops on "__HAL_UNLOCK(hspi);" breakpoint, doing a "Step Over (F6)", I see the "hspi2->lock" var turn to UNLOCKED;

4. When the application stops on the first command of "HAL_SPI_TxCpltCallback", the "hspi2->lock" still keeping the same value (UNLOCKED);

5. and the debugger works as I'm expecting.

Situation2:

1. I've put a breakpoint on "__HAL_UNLOCK(hspi);" line and in the first command of my callback function; (same as before)

2. Run the application from the beginning, which send a simple command after 1s running; (same as before)

3. When the application stops on "__HAL_UNLOCK(hspi);" breakpoint, I do "Resume (F8)" (insteaded "Step Over"). Because of the Resume command, I can't see if "hspi2->lock" change it's value;

4. When the application stops at the first "HAL_SPI_TxCpltCallback" command, the "hspi2-> lock" remains "LOCKED", it appears that "__HAL_UNLOCK (hspi)" from stm32f0xx_hal_spi.c has not been executed.

As you can see, I just change the debug command, and the behavior was totally different. And running the application the problem happens the same way as the Situation2.

My workaround was include the "__HAL_UNLOCK(hspi);" on the callback function, once this function must be called after the whole process happens.

An I did something wrong? Did happens with someone else?! There's an advice to fixed this problem without forcing "__HAL_UNLOCK(hspi);" out of stm32f0xx_hal_spi.c?

Thank you in advanced!!!

1 REPLY 1

I think refactoring the code with a clean/robust implementation will be the less perilous path than trying to understand the wtf model that tries to serialize operation across foreground and interrupt/callback context.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..