SPI/USB will drop large multiple of packets in a row. Can't keep up with 1 Mbps on nrf52840 dk?

[ryerye120]

Hi,

I'm using an nrf52840 dk to query another device over spi and then pipe the response back USB to a host PC. Ideally, we're piping data at 1 Mbps (which should be very much doable for USB) and for a little bit, it will work perfectly. Then randomly we'll miss 4 kB worth of packets. After plotting the data stream it's become apparent that it's quite bad. We consistently lose at least a 3rd of our packets. Furthermore, the lost data is lost in chunks. Here's an example of a 'noisy' sine wave that we sent through the serial link.

I don't believe it's an issue with the spi because I've tied an oscope to the spi pins and observed perfect spi packets being transmitted at a rate of 1 Mbps (but I could only observe maybe 20 packets at a time and didn't decode them so ...). Given that we're missing consecutive packets, and it seems to happen more or less regularly, I think this might have to do with a USB overhead issue.  

Is there something I'm missing about USB? Is there an ideal packet size that I should send over the USB at a given moment? I've played with the following settings but they've seem to make no difference:

• APP_USBD_CONFIG_SOF_HANDLING_MODE (tried both normal and compress queue)
• APP_USBD_CONFIG_EVENT_QUEUE_SIZE (Tried setting this to the max, 64, in case I was trying to send packets too frequently and they needed a larger queue)

I'm pretty new with USB communication so any help would be amazing! 

EDIT: I've started saving the data to a buffer on the dev kit and reading it all out at once (ideally this decouples the SPI and USB). While I'm missing significantly fewer packets, I am still missing a few. Now I'm getting 75%-85% of all my packets. So I guess this means there is some function that's interrupting the SPI's interrupt, possibly? I've tried bumping the SPI interrupts priority but it doesn't seem to have changed anything. I'm completely out of ideas so any pointers would be a huge help.

Thanks,

Ryan

[Nguyen Hoan Hoang]

USB is 12MHz no way USB can be slower than SPI.  The problem is more likely in your SPI code.  Have you validate that you got all the data through SPI before sending to USB ? Are you also sure the SPI sender actually sent all the data correctly.  Validate each step of the way in order to find where the issue is.

[ryerye120]

Yea I agree that there seems to be an issue with the SPI code. I tried writing all the SPI data to a buffer and then reading that out over USB after the fact (in order to decouple the two) and I still had missing packets. I rarely missed a single packet, rather large chunks of adjacent packets were missed so it seems to me that there is some process interrupting the SPI.

But even that seems odd since the SPI should mostly be handled by hardware.

Do you have any suggestions for testing the SPI out on its own? Using the NRF Log is a no go because it will sometimes cause issues with the SPI's chip select driver and limit data throughput to <1Mbps.

[Mojo]

You can send a packet containing prbs code.  Google 'prbs'.  On the receiving side check the code for error.  You only printout when there is an error.  Then you'll know whether your spirits transfer is good. I am assuming you are handling Master/Slave.