cancel
Showing results for 
Search instead for 
Did you mean: 

CubeMx F4 1.11, SPI polling mode wrong implemented, crash bug

taraben
Senior
Posted on April 23, 2016 at 23:45

Hello 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
1 REPLY 1
Rosiney Silva
Associate II
Posted on April 28, 2016 at 15:46

Hello,

Very good description of the problem

. I had the same issue when reading a memory fram (SPI in 20 MHz). In reading was sporadic data loss. I made the suggested changes 

in my

code

(''polling code to a strict sequencial order of execution'') and errors disappeared. Is now expected to St fix this bug.

Observation: English is not my native language.