I have a QN9080 operating as a slave on a SPI bus controlled by an MK22 master device. The QN9080 is using SDK 2.2.0 and the MK22 is using SDK 2.3.1. The baud rate is 2 MHz. The QN9080 is using the same techniques described in the spi_polling_b2b_transfer_slave example that came with the SDK. The MK22 is using EDMA. Everything works fine if I am transferring less than 29 bytes. However, the QN9080 never recognizes the transfer as completed if I transfer 29 bytes or more and the callback function passed into SPI_SlaveTransferCreateHandle never gets called. The result is that my while loop waiting for the slaveFinished flag never exits.
If I look at the handle passed into the SPI_SlaveTransferNonBlocking function I can why the callback never gets called. I can see that
handle.txRemainingBytes = 0
handle.txRemainingBytes = 1
handle.toReceiveCnt = 1
After some trial and error, I found that I could fix the issue by changing one parameter in the MK22 master controller. My master configuration originally had lastSckToPcsDelayInNanoSec = 500. If I increase that to 1000, I can successfully transfer up to 47 bytes, but I see the same missing received byte on the slave side if I transfer 48 bytes or more. If I set lastSckToPcsDelayInNanoSec = 2000, I can successfully transfer 255 bytes. I didn't go any higher than that.
I would prefer not to have 1.5 us added to small byte count transfers just so I can support larger transfers. Is there anything I can do to reduce lastSckToPcsDelayInNanoSec back down to its original value? the problem appears to be delays in the QN9080's fsl_spi, but I am not sure exactly where the issue is. If I cannot improve the performance, can the MK22 master change lastSckToPcsDelayInNanoSec before each EDMA transfer, or does the entire initialization be performed again to change that value? If I can change lastSckToPcsDelayInNanoSec before the transfer, I can set it based on the number of bytes being transferred.
Finally, I am curious about why the lastSckToPcsDelayInNanoSec value affects the number of bytes I can receive. It looks like the QN9080's fsl_spi is using pointers for data buffering, so the number of bytes should not affect access times for updating the buffers. Can you tell me why this is happening