This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SPIS data corrupted?

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
  • 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?

    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

Reply Children
No Data
Related