nRF51422 won't sleep

RE: nRF51422 won't sleep

Radoslaw Koppel — Wed, 09 Dec 2015 08:55:02 GMT

In this very situation we really wants to be sure that every event is cleared just before calling __WFE and it is good example for using SEV, WFE, WFE sequence. But please read also my comment here: devzone.nordicsemi.com/.../ before implementing it into your code. This sequence may not be safe.

RE: nRF51422 won't sleep

TomWS — Tue, 24 Nov 2015 13:28:44 GMT

Yes, this last explanation is perfect! Thank you for helping me understand! Tom

RE: nRF51422 won't sleep

Einar Thorsrud — Tue, 24 Nov 2015 12:43:46 GMT

I am glad to hear this fixed your problem. The thing is that if nothing else is done in the main loop, as is often the case in a purely event driven application, then the order does not matter as it will basically result in the same set of instructions (except for the relative position of the jump). However, when you do other stuff in your main loop you have to get the order right.

RE: nRF51422 won't sleep

TomWS — Tue, 24 Nov 2015 12:34:55 GMT

Doh! Actually, this makes total sense to me, however, throughout this forum all the examples seemed to be the sequence that I originally used. I've reordered as you've suggested and, indeed, it DOES SLEEP!!! YAY! Thank you very much!

RE: nRF51422 won't sleep

Einar Thorsrud — Tue, 24 Nov 2015 12:21:59 GMT

Probably the problem is the way your code attempts to go to sleep. You are using this code:

    // Enter System ON sleep mode
    __WFE();
    // Make sure any pending events are cleared
    __SEV();
    __WFE();

But this will probably not do what you think. If we assume that a event is pending, then the first WFE (Wait for Event) instruction will not do what you expect, as the pending event will cause the CPU to wake up again immediately. Then the SEV (Send Event) instruction will signal an event to the CPU. Again, the CPU will wake up immediatly from the next WFE as a event is pending.

The correct order is this:

    // Make sure any pending events are cleared
    __SEV();
    __WFE();
    // Enter System ON sleep mode
    __WFE();

Here the SEV will make sure that a event is set, in case it is not. The first WFE will make sure the event is cleared. Thus after those two instructions we can be confident that there are no pending events. The last WFE will put the CPU to sleep.

RE: nRF51422 won't sleep

TomWS — Tue, 24 Nov 2015 11:38:55 GMT

Yes, my mistake on this part of the problem. I had been shutting down after program load and restarting with the SEGGER disconnected, but hadn't noticed any difference previously (probably because it's not sleeping in the first case), so didn't think it mattered. In this second case, I retried it and, once disconnected and restarted, the total board current is a respectable 2.5uA.

Thank you for pointing this out. However, what I'd really like to know is why the first piece of code won't sleep.

RE: nRF51422 won't sleep

Einar Thorsrud — Tue, 24 Nov 2015 10:27:53 GMT

Are you using a debugger (RTT printing etc.) when you say that power consumption is 2.3mA? when powered down? When measuring power consumption you should not use a debugger (this also means that you have to do a pin reset after programming before measuring), as the debugger interface consumes approximatly 1.2 mA.