Posted on April 23, 2016 at 23:45Hello all,
in version F4 1.11 the code for SPI has been changed from WaitForFlag execution style to if loops. (see Release Notes)
While this sounds ok it causes malfunctioning codesequences.
The problem is in TransmitReceive function only (probably).
We need a sequence in the form
1 write data register
2 wait to read received data
3 read data
4 goto 1) until end
To speedup things we might write to the transmit register 2nd byte before reading 1st byte in order to avoid small gaps in between the transmitted bytes.
Now we have
1) if tx register empty then write data
2) if read register full then read data
3) loop to 1) until txcount = 0and rxcount = 0
What really happened might be that
- tx becomes empty quickly, 1 byte in shift register and 1 byte in hold register
- rx is not read in time and the 2nd received byte will be read first
- the first received byte might not be moved to the users rx buffer
This explained condition might happen on fast SPI or on high ISR activity where main application is interrupted more often. Also depending on compiler optimisation level and stuff.
That means WE CAN NOT ASSUME SPECIFIC APPLICATION CODE TROUGHPUT.
The result is in undefined application behavour as is does not read the expected results in the receive buffer. We had a hard time to figure out what caused our application to malfunction.
We use the polling code for situations of small amount of data to be transfered via spi. i.e. reading status bytes. A wrong received status byte has troublesome consequences.
Please ST revert SPI polling code to a strict sequencial order of execution.
Regards Adib.
--
#bug-in-hal-spi #stm32-cubemx-hal-spi-stm32f4
