2019-06-12 09:29 AM
2019-06-12 09:37 AM
This is because the compiler writes 16 bit to the SPI DR, these 2x8 bit are queued in the FIFO.
Dig the HAL SPI function for the cast to ensure the compiler does a 8 bit write to the DR and not 16.
In the past, without the FIFO, the old SPI just ignore the MSB byte. not anymore...
2019-06-12 10:07 AM
The SPI->DR is sensitive to the width of the write on the bus
*((volatile uint8_t *)&SPI->DR) = value8bit;
2019-06-12 01:27 PM
Thank you so much, it work properly now!
2019-06-12 09:05 PM
This post will contain no useful information, just a complaint about ST's documentation.
I too fell into this trap and wasted 3 days trying to figure out what was wrong before finding the answer in older posts on this forum (the search feature worked well -- once I knew what I was looking for).
Mine was in a different context -- SPI on the STM32F767zi -- but the problem and solution were the same. Posts
"STM32f302cc SPI code assistance needed, March 25, 2018" and "SPI not working on port B, February 17, 2016", with the magic solution from members of the usual non-official-but-only-ones-who-actually-help "ST Support Team", Clive Two.Zero and waclawek.jan.
In my case I had no idea that16 bits were being shifted out on SPI MOSI instead of the 8 I had specified in the SPIx_CR2 register's DS field, which is specifically documented as "Bits 11:8 DS [3:0]: Data size These bits configure the data length for SPI transfers: ..." All I knew was that my next write on MOSI was returning the wrong bits on MISO. As with all bugs, the reason was obvious once I knew what the problem was (the correct MISO bits had already been transferred on the 2nd eight bits of the unintentional 16-bit MOSI).
Yes, the chip's actual behavior *is* documented -- buried and glossed over in a long section far away from SPIx_CR2::DS description, reading, "The handling of FIFOs depends on the data exchange mode (duplex, simplex), data frame format (number of bits in the frame), access size performed on the FIFO data registers (8-bit or 16-bit)". Maybe there's a good hardware design reason for this craziness (the data size register doesn't really set the data size) but even if so there needs to be at least a note/reference/link that says, "Bits 11:8 DS [3:0]: Data size These bits ... BUT ARE ALSO INFLUENCED BY ...". Big red letters wouldn't hurt. This thread and the other ones prove I'm not the only one who finds this a problem.
And, yes, there's a good chance that ST considers the reference manuals an unnecessary expense anyway -- CubeMX/CubeIDE are all you need. I disagree, but I suspect that until I place my first order for 10e6 chips my opinion isn't going to change much.
2019-06-13 09:14 AM
I absolutely agree with you: bits DS [3:0] should take care about everything including type of access to the DR register and settings for the FRXTH bit.