NRF52 SPIM - send data as two byte pairs instead of one byte per interrupt

RE: NRF52 SPIM - send data as two byte pairs instead of one byte per interrupt

Petter Myhre — Sat, 20 May 2017 18:14:16 GMT

Please confirm that an initiated 2 byte transfer is interrupted in the middle. Please include the actual capture (not picture). Please include how you are calling nrf_drv_spi_transfer() and what your spi_event_handler() looks like. If you do another capture, please also include the chip select signal.

RE: NRF52 SPIM - send data as two byte pairs instead of one byte per interrupt

dmf3030 — Thu, 18 May 2017 16:20:34 GMT

Im on the SDK12.2, the code has alot going on right now and needs a clean down. Ill try to pull all the pertinent parts to link for testing. My most recent and most reliable solution is to send 26 byte chunks which causes the first two bytes, which are the most sensitive command bytes to seemingly always send together, while the later bytes can sometimes have extra time between but that is not a total deal breaker.

I posted in another question, but I guess the main question is whether you can block the soft device or any other interrupt from breaking in to a spim transfer reliably either with easyDMA or using the scheduler to put the transfer in main. Im finding it hard to find true documentation on how the easyDMA should function and if it is supposed to be an uninterrupted transfer. Also I'm not reading bytes back on the SPI, only sending if that gives me more options.

RE: NRF52 SPIM - send data as two byte pairs instead of one byte per interrupt

Petter Myhre — Thu, 18 May 2017 13:12:41 GMT

Strange. What SDK are you using? Could you share your complete code so I can test it here?

RE: NRF52 SPIM - send data as two byte pairs instead of one byte per interrupt

dmf3030 — Wed, 17 May 2017 20:16:25 GMT

So the next thing I tried was to break all my writes up into non blocking two byte transfers. I used the spi event handler to step to the next two bytes of my data each time around and then when finished I pushed my latch. I know this adds overhead to each transfer but as I said I dont have a problem unless the extra time is before a one bit and this two byte quick send was meant to stop that since I knew every first byte was all zeros. On the scope I was seeing two byte packets, fixing the flicker, but after watching I did every so often see the odd flicker. When I really stepped through some probed data I found that rarely my two byte packets were being split once again into single byte sends with an extra delay between which broke the data.

So this is a hack but is there a reason that two byte packet got broken up, am I writing too fast for the double buffer to fill?

RE: NRF52 SPIM - send data as two byte pairs instead of one byte per interrupt

dmf3030 — Wed, 17 May 2017 20:07:21 GMT

Okay so here is the update. First thing I did was enable EasyDMA in the config, I'm actually surprised it wasn't already enabled. Previously I was sending my data in blocking mode with no event handler so I just tried again with EasyDMA enabled and still was getting breaks in my SPI data. This is an LED driver so the results of the breaks can be seen as the occasional slight flicker as the first bit of a brightness register gets lost. I've attached a screenshot of the logic probe showing a data transfer with two gaps. The data may be slightly confusing because it shows the original data and clock from the NRF and then the retimed cascading data and clock from two more driver chips. So so far the EASYDMA doesn't seem to block the Soft device from jumping in unless I've implemented it wrong. logic probe screencaps

RE: NRF52 SPIM - send data as two byte pairs instead of one byte per interrupt

dmf3030 — Wed, 17 May 2017 17:30:31 GMT

Definitely on an NRF52, but didnt know the EasyDMA blocked interrupts. Hopefully thats the quick fix I need, I'll report back and close this if it works.

RE: NRF52 SPIM - send data as two byte pairs instead of one byte per interrupt

Turbo J — Wed, 17 May 2017 16:59:51 GMT

Are you really on a NRF52x? Why don't you just use the SPIM with EasyDMA? Allows up to 255 bytes without any interrupt in between.