SPI bug 5.114 / PIC18F45K42

[newguy]

Alerted CCS to this issue a couple of days ago. Today they confirmed it's a bug and I wouldn't be surprised to see it fixed in the next update.

I use the traditional (old) way of using SPI:
- setup_spi()
- use spi_write() and spi_read() thereafter.

I did not attempt to try the newer #use spi and spi_xfer() method.

The issue is that spi_read(0x00) always returned 0, even though I could see (via logic analyzer) that the IC was not clocking back 0. My workaround was to change the reads to be spi_write(0) followed by a read of the SPI1RXB register, which would contain the correct data.

CCS just confirmed that spi_read(0) immediately returns and fetches the contents of SPI1RXB before the SPI peripheral even starts generating the 8 clocks.

[Ttelmah]

Historically that is what spi_read _did_.
If you wanted to read a byte and clock it, the standard syntax was to use:

val=spi_write(0);

Which forces a clock and returns the data.

Now they changed to allow a value to be passed to spi_read as you are
doing, a while ago. It sounds as if the update was not handled correctly
on this chip/compiler version.
I must admit I'd still use the older syntax, and this has always worked
fine....

It'd be quite interesting to see when this syntax changed.