• State Suggested Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 69 subscribers
  • Views 1489 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 235530
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SPIS data corrupted?

JeanMBoones

Hello, working on an incredibly frustrating problem.  

We have a 2-chip system and the primary chip (non-nrf) communicates with the nrf52840 as a SPI master, and of course the nrf chip is configured as a SPI slave (SPIS).  We had an issue with the cryptocell where an interrupt flag was keeping the nrf chip from really sleeping.  In this state, the SPIS system was working fine.  Now, I have this strange issue.  It appears that after we fixed the sleeping issue, the SPIS RX data is getting corrupted.

For example.  The master sends a series of 0xA5s to indicate to the slave to start sending.  The slave checks this value, but instead of receiving a 0xA5, we get an 0x25.  Its as if the first 2 bits are corrupted. This throws off the system and causes problems.

The additional weirdness is that if the debugger is attached (isystems), everything works fine.  If I remove the debugger, the issue shows up.  It seems like the chip is asleep when it shouldn't be and having something observe the system causes the issue to go away.  

  • 0

    bad.tif    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.

  • 0
    JeanMBoones said:
    We had an issue with the cryptocell where an interrupt flag was keeping the nrf chip from really sleeping.

    Let me guess. Was it the floating point interrupt?

    JeanMBoones said:
    The additional weirdness is that if the debugger is attached (isystems), everything works fine.  If I remove the debugger, the issue shows up.

    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

  • 0

    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.

  • 0 in reply to Einar Thorsrud

    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.

Related