SPIS data corrupted?

RE: SPIS data corrupted?

JeanMBoones — Fri, 06 Sep 2019 17:02:54 GMT

Yup, I think this is the problem. Thanks!

RE: SPIS data corrupted?

JeanMBoones — Fri, 06 Sep 2019 17:02:31 GMT

Yep, I think thats it. I played around with longer delays on CSN and it resolved the issue. Unfortunately our SPI peripheral isnt terribly flexible. We will need to find a way to make it longer. Thanks.

RE: SPIS data corrupted?

Einar Thorsrud — Fri, 06 Sep 2019 13:47:20 GMT

Hi,

The issue is probably caused by a too short delay between CSN is asserted and the first bit is clocked out on the bus. I see from your plot that it is about 2 μs, and so within that time you must fit the latency of the SPIS peripheral itself (~1 μs) and the startup time of the HF clock (~3 μs), and that does not work. So the solution here is to adjust the implementation on the SPI master device, increasing the time between the CSN is asserted and the start of the transaction.

RE: SPIS data corrupted?

wpaul — Thu, 05 Sep 2019 23:33:21 GMT

[quote userid="25970" url="~/f/nordic-q-a/51810/spis-data-corrupted"]We had an issue with the cryptocell where an interrupt flag was keeping the nrf chip from really sleeping.[/quote]

Let me guess. Was it the floating point interrupt?

[quote userid="25970" url="~/f/nordic-q-a/51810/spis-data-corrupted"]The additional weirdness is that if the debugger is attached (isystems), everything works fine. If I remove the debugger, the issue shows up.[/quote]

When the debugger is connected, it prevents the CPU from going into low power sleep mode. I'm pretty sure this is because the CPU would no longer respond to the debugger otherwise.

It can take the CPU a certain amount of time to come out of sleep mode and resume executing. For example any PLL clock circuits are powered down, you need to wait a certain amount of time for them to achieve lock when they power up again.

My question to you was going to be "what exactly are you doing to trigger a wakeup on the slave" but it sounds like the answer is asserting the chip select line (CSN).

I don't think you can eliminate or shorten the wake-up time of the slave. That means you need to take some action on the master side. After you assert the CSN pin on the master, add a delay to give the nRF52840 to wake up. _Then_ start the SPI transfer.

-Bill

RE: SPIS data corrupted?

JeanMBoones — Thu, 05 Sep 2019 17:20:36 GMT

devzone.nordicsemi.com/.../bad.tif devzone.nordicsemi.com/.../good.tif

Here are some scope images, it almost looks like in the bad.tif condition, the nrf chip waits 8 clocks before sending out the data. Almost as if the SPI was not recognizing the CSN line until it was too late.