nRF52 RTC2 stops generate CC interrupts periodically

Hi, i'm trying to fix strange issue in my code.

Setup is:

Nrf52832 based custom board with s132 enabled and running, gpiote, spi. Also I have app_timer enabled.sdk15. I have sensor connected over spi with interupt line connected to nordic gpio. 

When rtc2 cc interrupt happens in interrupt handler I request SWI interrupt. In swi interrupt handler I setup sensor over spi and wait for gpiote interrupt. When interrupt happens I request swi interrupt and readout sensor over spi. I use swi to get code running with higher priority than in main loop.

The problem is in rtc2 interrupt. Sometimes it stuck for exactly 0xffffff (24bits) clock cycles and than returns to normal operation. With debugging i've got that rtc2 counter keep counting but cc interrupts seemd to be masked. This behaviour catched frequently when more gpiote interrupts received. During rtc2 hang period app timer on rtc1 works as expected (send logs periodically). 

In what direction should I digg ti figure out the root cause?any known errata?

  • I do not know what your problem is, but I want to give you some general advice on periodic readings over SPI:

    There's no need to use the CPU unless you need to change the address or content of the SPIMs Tx/Rx buffers. 

    What you'll want to do is to set up the SPIMs Tx and Rx buffers beforehand and then trigger the SPIM TASKS_START via the RTC CC event via PPI — Programmable peripheral interconnect. You'll also want to fork the RTC CC event to trigger the RTC TASKS_CLEAR to reset the counter value and thereby creating an infinite loop.

    If you do need to change the address of the tx/rx buffers you can do so immediately after the previous SPIM transaction has started, on the SPIM EVENTS_STARTED (TXD.PTRTXD.MAXCNTRXD.PTR, and RXD.MAXCNT are double buffered ). This means that you'll have plenty of time to update the buffers for the next transmission. 

    There's also a EasyDMA list feature where the SPIM can increment over a list of buffers automatically. This enables you to sample the sensor say a 100 times into 100 buffers that's place consecutively in RAM without waking up the CPU.

    In the end you'll want to end up with a system where you only use the CPU to configure the sensor driver and only use the CPU when you need to access the sensor samples, to analyze, transmit via radio, or store to flash. 

    1. How long are the SPI transactions in time, alternatively how many bytes at what clk frequency?
    2. How often do you need to sample the sensor? 
    3. What is the maximum latency you want from the time the sensors has a sample and until you'll want to have access to it? 
    4. Edit:
      Why do you need to use the RTC at all, it seems to me that all you'll need is to prepare the tx/rx buffers beforehand and use GPIOTE to trigger the SPIM TASKS_START, and then prepare the tx/rx buffers for the next transaction (if needed) after the EVENTS_STARTED wakes up the CPU. 
Reply Children