• State Suggested Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 70 subscribers
  • Views 1528 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.  

Parents
  • 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.

Reply
  • 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.

Children
Related