2018-08-02 10:01 AM
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!!!
2018-08-09 08:50 PM
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.