Odd Sleep operation

Discuss PIC and electronic related things

Moderators: David Barker, Jerry Messina

Post Reply
SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Odd Sleep operation

Post by SHughes_Fusion » Tue Jun 09, 2015 3:51 pm

I've got a system set up using the PIC18LF26K22. On this I've implemented a power-down mode where if nothing has happened for a certain period of time the unit will sleep and check a switch and charger status inputs to wake up.

I've read that it is possible to 'stack' SLEEP commands on a PIC so if, for example, you want a short watchdog timeout but a longer sleep period you can just use multiple SLEEPs and when the watchdog wakes from the first the processor will just see the next and go straight back to sleep.

I've got all interrupts disabled and nothing that would wake the unit from sleep other than the watchdog.

My code works fine with a single SLEEP. As soon as I add a second the processor resets as soon as the powerdown code executes.

Anyone got any ideas?

Even more oddly, I've read the status of RCON and the bits suggest a power-on reset!

Very occasionally I don't get this reset immediately but when this happens, the unit does not respond to the inputs which exit power-down mode. It's almost as if it has locked up. Usually the reset does happen within a few tens of seconds when this happens.

My code is:

Code: Select all

        OSCTUNE = 0                     // Disable PLL
        OSCCON = %00000000              // Select 31kHz oscillator
        WPUB = PowerDownPullUps         // Enable battery status and in/lever pull-ups only
        While true
          INTCON2.7 = 1                 // Disable pull-ups
          Asm
            Sleep                       // Sleep processor until Watchdog wakes it
            Sleep                       // Multiple sleep commands extend the period of maximum power saving.
          End Asm
          ClrWDT
          INTCON2.7 = 0                 // Global Enable pull-ups 
          If BattStat1 <> BattStat2 Then Break EndIf        // Battery charging or full, move back in to active mode.                                                 
          If LeverSwitchPos <> Switch3 Then Break EndIf     // Lever has changed, back to active mode
        Wend
        ClrWDT
        OSCCON = %01110000              // Ramp oscillator up to 16MHz
        OSCTUNE = %01000000             // Enable PLL so we are running at 64MHz 

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: Odd Sleep operation

Post by Jerry Messina » Tue Jun 09, 2015 5:24 pm

I've never tried that.

How about adding a NOP in between the two SLEEPs and see if that makes any difference?

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Odd Sleep operation

Post by SHughes_Fusion » Wed Jun 10, 2015 7:51 am

Good idea, Jerry. NOPs don't seem to help, but adding a CLRWDT between the two sleep commands does.

It has also massively reduced the standby current.... I'm wondering now if there is an issue with the Sleep command on this processor. My understanding is it is supposed to clear the watchdog before entering sleep, I can't prove this but it would appear that this isn't happening.

I can't see anything in the errata - am I misunderstanding how Sleep works or is something very odd going on?

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: Odd Sleep operation

Post by Jerry Messina » Wed Jun 10, 2015 10:06 am

Looking at Section 28 in the FRM I just noticed this...
When interrupts are globally disabled (GIE cleared) and any interrupt source has both its inter-
rupt enable bit and interrupt flag bit set, one of the following events will occur:

• If an interrupt condition (interrupt flag bit and interrupt enable bits are set) occurs before the
execution of a SLEEP instruction, the SLEEP instruction will complete as a NOP . Therefore,
the WDT and WDT postscaler will not be cleared, the TO bit will not be set and PD bit will
not be cleared.

• If the interrupt condition occurs during or after the execution of a SLEEP instruction, the
device will immediately wake-up from SLEEP.The SLEEP instruction will be completely
executed before the wake-up. Therefore, the WDT and WDT postscaler will be cleared, the
TO bit will be set and the PD bit will be cleared.

Even if the flag bits were checked before executing a SLEEP instruction, it may be possible for
flag bits to become set before the SLEEP instruction completes. To determine whether a SLEEP
instruction executed, test the PD bit. If the PD bit is set,the SLEEP instruction was executed as
a NOP .

To ensure that the WDT is clear, a CLRWDT instruction should be executed before a SLEEP
instruction.
I wonder if that first condition is happening, and the SLEEP is getting executed as a NOP. That would explain what you're seeing.

Also, that last bit is something I've never noticed before (I added the bold). Everything I've read has stated that the WDT is cleared when a SLEEP instruction is first executed, and that's the way I've always used it. I guess I'll start adding one.

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Odd Sleep operation

Post by SHughes_Fusion » Wed Jun 10, 2015 10:12 am

Thanks, Jerry, I'd not spotted that. I was working on the information in the datasheet which states:
The WDT timer and postscaler are cleared by any one
of the following:
• executing a SLEEP instruction
• executing a CLRWDT instruction
...
What you have found seems to suggest that is not correct, or may not be correct. I do sometimes wonder how accurate MCHP datasheets are - you get the impression they take another datasheet and edit it to suit the new device rather than writing a new one from scratch. I've seen a few things that have looked wrong, it must be so easy to miss something like this that did apply to other devices but doesn't apply to this one.

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Odd Sleep operation

Post by SHughes_Fusion » Thu Jun 11, 2015 11:06 am

Just a quick follow-up to this. I'm no closer to finding out what is wrong but the more I delve in to this the more I suspect either a datasheet error or a silicon fault.

In the datasheet, figure 24-1 shows more detail on the watchdog. The SLEEP command is not shown as an input to clear the watchdog, only a means of selecting what a watchdog time-out does.

What it doesn't explain is the value of RCON after the unit resets is that of a power-on reset, not a watchdog reset... I suspect there is some interaction going on between the two sleep commands and the watchdog which is causing the processor to perform a power-on reset. The only other possibility I can think of - and this seems very unlikely - is that something is happening which is causing massive power drain and causing the regulator to go in to shutdown, thus turning the processor off and back on again.

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: Odd Sleep operation

Post by Jerry Messina » Thu Jun 11, 2015 11:50 am

I wonder if adding the CLRWDT instructions is masking out what's going on since it'll set both the RCON.TO and PD bits, making RCON look a lot like a power-on reset.

It certainly isn't clear what's going on, esp with the seemingly contradictory information. Mchip are notorious for cut and paste errors in the datasheets, so that doesn't help.

Might be time to open a support ticket, show them the asm code, what you're seeing, and ask them how to do what you're looking for. Be prepared to wait... it tends to take a while and they have a tendency to close the tickets w/out really providing an answer (as if them just sending you a response is good enough).

Keep us posted.

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Odd Sleep operation

Post by SHughes_Fusion » Thu Jun 11, 2015 12:53 pm

Maybe I'm misunderstanding how RCON works but I'm getting RI, TO and PD set and BOR and POR cleared.

My understanding is that SLEEP sets TO and clears PD. I believe that TO will be cleared should the watchdog cause a wake or reset so it appears this is not what is happening.

My code writes RCON to EEPROM then sets RI, POR and BOR which is enough for me to tell what sort of reset it was.

I know what you mean about them closing support tickets - I'd asked for more info on the RN4020. Got an answer back saying they needed to go away and look in to it and they then closed the ticket! It's also not good that you can't re-open tickets - as you say, just because they've given you an answer doesn't mean they've solved the problem or even understood the question...

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: Odd Sleep operation

Post by Jerry Messina » Sat Jun 13, 2015 12:07 pm

I've been playing around with sleep using an 18F26K22, and I seem to get the expected results shown in the datasheet.

I have config BOREN = ON, PWRTEN = ON, and WDTEN=SWON

at powerup-
rcon: 00011100

after MCLR reset-
rcon: 01011111

after a sw RESET instruction-
rcon: 01001111

after single sleep-
sleep()
nop()
rcon: 01010011

after chained sleeps-
sleep()
nop()
sleep()
nop()
sleep()
nop()
it wakes up normally after 3xWDTPS settings and I get:
rcon: 01010011

I'm not adding any extra CLRWDT instructions, and all interrupts are disabled and masked out.
Every time I read RCON afterwards I set RCON = RCON or %011111111 to make sure all the bits are set.

EDIT:
I changed WDTEN = ON, and removed the nop's so the chained sleep's were just-
sleep()
sleep()
sleep()

and got the same result (normal extended sleep with rcon: 01010011). I don't know what the power consumption is doing... that's a bit hard to measure w/the setup I'm using.

for ref, I've got sleep() defined as

Code: Select all

public inline sub sleep()
   asm
      sleep
   end asm
end sub

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: Odd Sleep operation

Post by Jerry Messina » Sat Jun 13, 2015 2:58 pm

I take that back. There's definitely something funny going on.

If I do this:

Code: Select all

            sleep()
            nop()
            sleep()
            nop()
it seems to work reliably.

However, if I do this:

Code: Select all

            sleep()
            sleep()
sometimes it works, but sometimes it never comes out of sleep! I have to do an MCLR reset to get it back.

I wonder if it's something to do with the prefetch queue. I'd have to go back and check, but it's my understanding that while the first instruction is executing it's actually fetching the next instruction during one of the four Tosc periods. I don't know if that gets dumped during a sleep or not, but it seems a lot happier with nop() after each sleep(), otherwise the WDT seems to get in an odd state.

I don't get a reset, but then again I don't get anything. Maybe there's a note somewhere about this but I don't recall seeing it.

update:
This seems to work too:

Code: Select all

            clrwdt()
            sleep()
            clrwdt()
            sleep()
I wonder if that note in the FRM about "always do a clrwdt before sleep" should actually read "never do back-to-back sleep instructions". It seems just as happy with a nop vs a clrwdt.

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Odd Sleep operation

Post by SHughes_Fusion » Mon Jun 15, 2015 7:50 am

Hi Jerry,

Great that you've replicated it - makes me happy that there isn't a bigger issue with my code / hardware.

I do sometimes get it locking up but more often it does reset. Whether that is something to do with the fact my system is battery powered or not I don't know.

Nothing back from MCHIP yet, I hope they will update the docs when we get a resolution to this so the datasheet clarifies this usage.

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Odd Sleep operation

Post by SHughes_Fusion » Wed Jul 08, 2015 9:55 am

Eventually got a reply back from Microchip. They can't recreate it... The code sample they sent me indicates they've not understood the issue. They asked for a code sample that shows the issue despite me having already sent one. They they marked the issue as resolved.

It's a good thing there are plenty of user support forums as getting official support seems to be next to impossible!

Post Reply