CCM DMA Corruption

[freelon]

Hi All, 

I’m running a proprietary RF protocol on an nRF52832 and am seeing some corruption of data when it passes through the CCM. The first byte is the only data that is corrupted, and it happens periodically.

The issue disappears when I remove __WFE() from our main loop.

I found this errata (109) and found that the symptoms match what we were experiencing, even though the CCM is not listed as one of the hardware modules affected by the errata.

I applied the clock workaround described in section 3.7 of the document above, and found that it fixed the issue we were seeing. 

We didn’t expect the above change to resolve our problem because we thought the 64MHz HFCLK clock (in our case derived from 32MHz HFXO) would be running continuously.  We start the clock in our initialization and do not turn it off.  Furthermore we derive LFCLK (for app_timer) from HFCLK and have several app_timer’s running in REPEAT mode.  Overall we believed HFCLK would always be running but now we are wondering if that is the case.What are the details of 64MHz HFCLK module being gated by app_timer (which uses RTC1) or other modules?

We are under the impression that we are keeping the 64MHz clock on at all times anyway, since we start the clock in our initialization and do not turn it off at any point, and we don’t understand why this errata applies in our situation. Is there some clock gating that happens by default? 

Thanks,
Adam

[Sigurd]

Hi,

As far as I know, errata 109 does not affect CCM, but I will double-check this.

It could perhaps be this errata as well, https://infocenter.nordicsemi.com/index.jsp?topic=%2Ferrata_nRF52832_Rev2%2FERR%2FnRF52832%2FRev2%2Flatest%2Fanomaly_832_220.html

Are you seeing this issue on 1 particular nRF52832 chip, or do you see the issue on several chips?

[freelon]

Any update on confirming whether 109 affects CCM? 

This is on many nrf52832 chips - it has been tested across 10-15 chips purchased at different times. 

[Sigurd]

freelon said:

Any update on confirming whether 109 affects CCM? 

 We are looking into it.

We start the clock in our initialization and do not turn it off.

 1) What clock are you referring to here? HFCLK? Can you post some code that shows how you do this?

If this is the HFCLK, I assume you are you using hfclk_start()  / nrfx_clock_hfclk_start(), or doing something like this? :

  // Start HFCLK from crystal oscillator. The radio needs crystal to function correctly.
  NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
  NRF_CLOCK->TASKS_HFCLKSTART = 1;
  while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);

To check if the HF clock is running, you can use nrf_drv_clock_hfclk_is_running() / nrfx_clock_hfclk_is_running()

What are the details of 64MHz HFCLK module being gated by app_timer (which uses RTC1) or other modules?

The app_timer/RTC1 does not use the HFCLK directly, it uses the LFLCK, which then is clocked by internal 32.768 kHz RC oscillator, 32.768 kHz crystal oscillator OR 32.768 kHz synthesized from HFCLK.

Furthermore we derive LFCLK (for app_timer) from HFCLK

2) So when you start the LFCLK, you set the source to be 32.768 kHz synthesized from HFCLK, correct?

[freelon]

Yes I was referring to the HFCLK.

This is how we initialize our clocks

// HFCLK - start
NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
NRF_CLOCK->TASKS_HFCLKSTART = 1;
while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0) {
}

// LFCLK - source = Synth (synthesized from HFCLK)
// - stop LFCLK before changing source
if (((NRF_CLOCK->LFCLKSTAT &
CLOCK_LFCLKSTAT_STATE_Msk) >> CLOCK_LFCLKSTAT_STATE_Pos) ==
CLOCK_LFCLKSTAT_STATE_Running) {
NRF_CLOCK->TASKS_LFCLKSTOP = 1;
}
NRF_CLOCK->LFCLKSRC = CLOCK_LFCLKSTAT_SRC_Synth << CLOCK_LFCLKSRC_SRC_Pos;

// LFCLK - start
NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
NRF_CLOCK->TASKS_LFCLKSTART = 1;
while (NRF_CLOCK->EVENTS_LFCLKSTARTED == 0) {
}

[Marjeris Romero]

Hi,

I am sorry for the late reply, Sigurd has been on vacation and I have taken over this case, but because of summer vacation our response time is a bit slow right now.

Our team wants to know if the clock is running continuously or not in your application?

I found this errata (109) and found that the symptoms match what we were experiencing, even though the CCM is not listed as one of the hardware modules affected by the errata.

It can look like CCM can be affected from errata 109, but still pending some testing to confirm. A possible workaround being mentioned could be to start the CCM from the CPU instead of through PPI, so the DMA channel don't start the 64MHz on its own but have 64MHz running for some cycles befroe first byte, but I am still pending more information from the team.

Best regards,

Marjeris