QN9080 Missing Last SPI Byte

[rickdickerson]

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

[gerardo_rodriguez]

Hello Rick,

I was able to replicate this issue by running the QN9080 spi_polling_b2b_transfer_slave example at 2Mhz. It works fine at 500kHz, so my assumption is that the SPI data is received faster than what it takes the MCU to process the SPI interrupt and eventually loses data. I believe better performance could be achieved by enabling the SPI FIFOs, but let me run some tests on my side and I will give you an update on how to get it working at 2MHz.

Regards,

Gerardo

[rickdickerson]

Gerardo,

I am currently using BOARD_BootClockHSRUN (AHB_clock.outFreq = 32 MHz) because the SPI is the only portion of the device I had been using thus far and that is what the SPI demo projects recommend. I am now ready to implement the BLE portion of my application but I see that all of the BLE demo applications for the QN9080 use BOARD_BootClockRUN (AHB_clock.outFreq = 16 MHz). If I drop to a lower clock rate this problem may be exacerbated. Can I keep using BOARD_BootClockHSRUN with my BLE application, or should I drop down to BOARD_BootClockRUN and adjust lastSckToPcsDelayInNanoSec as needed with the slower clock?

Thanks,
Rick

[gerardo_rodriguez · Accepted solution]

Hi Rick,

I made more tests and indeed the issue at 2MHz baud rate only occurs when BOARD_BootClockRUN is used and the AHB clock is 16MHz. When the BOARD_BootClockHSRUN is used (32MHz AHB clock), there are no communication errors.

About the SPI FIFOs, it turns out the driver enables them by default and by changing its FIFO level trigger point made little effect when using 2MHz baud rate and 16MHz AHB clock. Another possible solution would be to use the DMA to offload processing power from the MCU and reach higher SPI speeds, but this would require some effort since currently there are no examples implementing this approach for the QN908x.

On BLE applications, you can use HSRUN without problems. In fact, if you enable the gBleUseHSClock2MbpsPhy_c macro in app_preinclude.h, the HSRUN function will be used instead. See board.c:

#if gBleUseHSClock2MbpsPhy_c
 BOARD_BootClockHSRUN(); 
#else
 BOARD_InitBootClocks();
#endif‍‍‍‍‍

Regards,

Gerardo

[rickdickerson]

Gerardo,

Thanks for confirming the problem. I am looking forward to seeing your solution.

Rick