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

Possible bug in nrf52832 LFCLK

[Bug Report] Possible bug in nRF52832 engineering release B. When LF XTAL oscillator is started, no event is generated.

NRF_CLOCK->LFCLKSRC = CLOCK_LFCLKSRC_SRC_Xtal;
NRF_CLOCK->TASKS_LFCLKSTART = 1;
while (NRF_CLOCK->EVENTS_LFCLKSTARTED == 0)   { };      // STUCK HERE FOREVER!!

The oscillator is actually started but no event is generated.

Parents
  • updated with code that worked (29.01.2016)

    Maybe it needs one clk cycle or two between selection of the clock source and starting the lfclk, try this below

    NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
    NRF_CLOCK->LFCLKSRC = (CLOCK_LFCLKSRC_SRC_Xtal << CLOCK_LFCLKSRC_SRC_Pos);
    __DSB();     //<-- This will wait until write buffers are emptied.
    NRF_CLOCK->TASKS_LFCLKSTART = 1;
    while (NRF_CLOCK->EVENTS_LFCLKSTARTED == 0)
    {
    }
    

    i do not have engineering sample B to test it with. If the above code works, then i should ask someone here to test out why the event missed.

  • I had to look that up and check that DSB (and DMB) explicitly wait for the Cortex M4 internal write buffer to clear before returning and yes they do, so that should be equivalent, yes. It might be good to put that into the 'functional changes' document for the nRF52, I think that's a better, more generic way of ensuring write synchronisation than the write-then-read method listed there and is better to learn in general.

    If you really want to test if it is due to the write buffer causing the issue, and whether DMB() fixes it, it would be better to move the EVENTS_LFCLKSTARTED = 0 before the LFCLKSRC set as that one extra write may hide the issue all on its own.

    I still don't know if it is the write buffer or not, it's just a suspicion.

Reply
  • I had to look that up and check that DSB (and DMB) explicitly wait for the Cortex M4 internal write buffer to clear before returning and yes they do, so that should be equivalent, yes. It might be good to put that into the 'functional changes' document for the nRF52, I think that's a better, more generic way of ensuring write synchronisation than the write-then-read method listed there and is better to learn in general.

    If you really want to test if it is due to the write buffer causing the issue, and whether DMB() fixes it, it would be better to move the EVENTS_LFCLKSTARTED = 0 before the LFCLKSRC set as that one extra write may hide the issue all on its own.

    I still don't know if it is the write buffer or not, it's just a suspicion.

Children
No Data
Related