I had a heck of a time trying to get SPI to work when I needed to do a transmit-only and then a distinct receive-only, on the same SPI bus (sometimes in the real world one needs to do such things!). Received data was constantly corrupted, almost as if extra clock edges were being inserted.
I enabled ROOE in the mode register, trying to force it to receive new data over top prior "dummy" data from the transmit-only operations. This did not seem to fix the problem.
I finally found that reading (and discarding) the useless received data was REQUIRED for it to correctly receive later data. Maybe this will save someone else a lot of aggravation.
The latest version of the K64 reference manual contains a new note (I think it is the one on CLR_RXF on p. 1486) that sort of addresses this. But I could read the wording of that note several times and not get what it's talking about :smileyhappy:
It's a shame there can't be some truly useful applications information on using modules like the DSPI, that have been around forever. IMHO there shouldn't be any mysteries or cryptic notes about getting something that simple to work correctly, and the API stuff is pretty much useless for anything but the most straightforward use case.
The SPI module always transmit and receive data at same time. In half-duplex mode, since you know how many bytes you have sent, you know how many dummy receive bytes you should ignore.
There are many half-duplex demo in FRDM-K64F\boards\frdmk64f\driver_examples\dspi. If customers can reuse these demo code, they can speed up their project. To be honest, the structure of most peripherals in K64 is too complex to understand. Reuse the demo code is the best way for customer.