Possible bug in nrf52832 LFCLK

RE: Possible bug in nrf52832 LFCLK

Susheel Nuguru — Fri, 29 Jan 2016 09:36:06 GMT

Then RK got it right, it was for sure a write buffer issue. Good that it worked. I have created an internal ticket to update the functional changes document to use memory barriers. Hopefully infocenter will be updated soon.

If there is nothing else to do in this thread then can you please accept my updated answer by clicking ✓ on the left side of it so other see this thread as Green.

RE: Possible bug in nrf52832 LFCLK

KLWP0101 — Fri, 29 Jan 2016 09:25:31 GMT

Thanks for valuable comments. I got it working by using the following code:

NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
NRF_CLOCK->LFCLKSRC = (CLOCK_LFCLKSRC_SRC_Xtal << CLOCK_LFCLKSRC_SRC_Pos);
__DSB();
NRF_CLOCK->TASKS_LFCLKSTART = 1;
while (NRF_CLOCK->EVENTS_LFCLKSTARTED == 0)
{
}

Weird thing is that now I can't get it to non-functional any more. At the moment I only have one specimen to test. I will use the code above because don't want to get burned with this.

RE: Possible bug in nrf52832 LFCLK

RK — Thu, 28 Jan 2016 17:29:36 GMT

Should have linked to it, it's this one. It's a great redux of the major differences between the nRF51 and nRF52 processors.

Hopefully now the original poster can test out a few of these solutions and see if it points to the issue, which is quite odd.

RE: Possible bug in nrf52832 LFCLK

Susheel Nuguru — Thu, 28 Jan 2016 16:03:00 GMT

I agree that EVENT_LFCLKSTARTED = 0 should be moved to up to test if this a buffer issue. I have not seen the funtional change document for nRF52, should be in the infocenter, i will read it and see if it needs any improvements. Thanks for pointing that out.

RE: Possible bug in nrf52832 LFCLK

RK — Thu, 28 Jan 2016 14:20:40 GMT

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.

RE: Possible bug in nrf52832 LFCLK

Susheel Nuguru — Thu, 28 Jan 2016 13:41:39 GMT

Yes, It is possible. In that case inserting _DSB() in between setting the clock source and starting the clock should handle that. Do you think the below code fits?

NRF_CLOCK->LFCLKSRC            = (CLOCK_LFCLKSRC_SRC_Xtal << CLOCK_LFCLKSRC_SRC_Pos);
NRF_CLOCK->EVENTS_LFCLKSTARTED = 0; 
__DSB();
NRF_CLOCK->TASKS_LFCLKSTART    = 1;

while (NRF_CLOCK->EVENTS_LFCLKSTARTED == 0)
{
    // Do nothing.
}

RE: Possible bug in nrf52832 LFCLK

RK — Thu, 28 Jan 2016 13:04:56 GMT

agreed - however I wondered if the two writes, the one to the LFCLKSRC and LFCLKSTART end up getting committed at the same time because they get buffered and flushed together. I don't know what the LF clock would do if it gets both registers written at exactly the same time, possibly something a bit indeterminate.

I'm just guessing at possibilities, I know the write buffer exists but I still don't quite have a good handle on exactly when it may or may not need a flush.

RE: Possible bug in nrf52832 LFCLK

Susheel Nuguru — Thu, 28 Jan 2016 12:42:48 GMT

RK, but he said that it is stuck in the while loop for ever, that is the part that confused me. If it is the write buffer then it should have exited the while loop in few cycles.

RE: Possible bug in nrf52832 LFCLK

RK — Thu, 28 Jan 2016 11:50:34 GMT

This sounds a little bit like the write buffer scenario mentioned in the porting notes. I wonder if the write to LFCLKSRC isn't completing before the write to LFCLKSTART, or basically they end up completing together and so the source isn't really set and the clock event doesn't get sent.

You could try reading NRF_CLOCK->LFCLKSRC after writing it to force the write buffer to clear.

I think we're going to see this write-may-need-read scenario catching people out, it caught me out last week!

RE: Possible bug in nrf52832 LFCLK

Susheel Nuguru — Thu, 28 Jan 2016 11:03:40 GMT

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.