SLEEP mode 16F628A

I have a 16F628A as an infrared rcvr/xmtr pair and the data is transferred fine but having some intermitent problems. (It may be my receiver breadboard, if my code looks alright....it may well be the breadboard.....it works off and on).

I'll junk the breadboard if the code looks ok.

Neverthe less, I'd like to check some things and also want to make sure that the code is letting the pic sleep.

(1) If you're using the PORTB.0 interrupt, do you have to enable the PORTB pullups? If so, does it set the whole port or can you assign the pullups individually? (I'll have to use an external 10k...if I need to)

(2) When you come out of sleep and you see a high pulse on PORTB.0 and go to a routine.....at some point you need to reset the B.0 flag, right?
INTCON.1 = 0

My code for the Xmtr is basically as follows....I'm using 1n4148 steering diodes at every switch to take PORTB.0 high... (and wake up chip?).

WDT is off.

START:

SWITCH.1 = PORTA.0 '10K PULLDOWNS ON ALL
SWITCH.2 = PORTA.1
ETC

SEROUT PORTB.7,T1200,[QUAL,SWITCH]

INTCON.1 = 0
IF SWITCH = 0 THEN LOWPWR
IF SWITCH >= 1 THEN START

LOWPWR:
INTCON.4 = 1 'ENABLE INTERRUPT
OPTION_REG.6 = 1 'LOW TO HIGH TRIGGER
@SLEEP
PAUSE 100
INTCON.4 = 0 'DISABLE INTERRUPT (Ok here?)
GOTO START

END


Thanks for any help on this.

Either I'm asking really stupid questions or (?) but I'm not having much luck with this forum.

Anyway....just wondering if my code is letting the PIC sleep....everything else seems to be working fine but I'm seeing some battery drain after just a few days.

Thanks.

--Mike
(picbasic novice)

Hi Mike,
Well, at a glance your code looks like it should let the Pic go to sleep, but I'm certainly not a pro!

On your two questions...

Quote:

---

(1) If you're using the PORTB.0 interrupt, do you have to enable the PORTB pullups? If so, does it set the whole port or can you assign the pullups individually? (I'll have to use an external 10k...if I need to)

(2) When you come out of sleep and you see a high pulse on PORTB.0 and go to a routine.....at some point you need to reset the B.0 flag, right?
INTCON.1 = 0

---

1) You don't have to use the built-in pullups if you don't want to - but be sure to use an external pullup / pulldown as needed otherwise. The entire port has its pullups enabled as a group (other Pic models allow setting individual pin pullups). When a pin is switched to output mode, the individual port pin pullup is automatically disabled.

2) The interrupt flag(s) should be cleared before exiting your interrupt service routine and resuming the 'normal' program.


You might consider putting some 'debugging' blinky LED outputs throughout your code for a visual indication of where the code is.

Arch

Well one thing's for sure, I'll add the 10k pullup on PORTB.0, there isn't one now.

I just didn't know....I mean obviously it's an input when acting as an interrupt but who's to say that as part of the INTCON.4 statement it doesn't automatically configure the internal pullup?....so there is always some question to ask when you're a beginning pic person.

Something isn't acting right....I have the xmtr on a PCB but the rcvr on breadboard so I'll just wait till I get it all on PCB's and everything stable.

2 fresh aaa cells in the xmtr and had close to 3 volts....but today about 2.6.....yet I understand in sleep mode, battery life should be close to shelf life?

Yup - the power consumption sounds high. It should be below ~10uA in sleep if everything is set up for low power operation.

The pullups will not be set automatically - you have to enable them. Same goes for the input/output states - enabling the interrupt does not set the pin to an input.

Arch

Hi Michael

I'm not sure if this will help. The sleep statement needs to be followed by at least a nop. Read the datasheet carefully - it has a mention of this. Anyway, I am too lazy to read it and point it out at this time. I use the 16F628A in sleep and successfully.

The statement sequence should be

@sleep
@nop
@nop

Also, make sure that the pending interrupt is cleared before you put the PIC to sleep.

Jerson

Ok....that's a new one. A NOP?

Everything I think is fine...as always a stupid mistake on my part by not taking PORTB.0 low with a pulldown and letting it float....(a great way to get "unpredictable" behavior).

It was probably sensing a false high and interfering with the sleep routine.

I had put a pause following sleep as I had read in the archives (Melanie?) suggested it's use, to let the PIC wake up and get some coffee.

Maybe what your saying is the NOP would do the same thing?

Sort of a safety buffer before it gets back to work?

See section 14.8.1 of the datasheet on page 110/168. This is the excerpt

When the SLEEP instruction is being executed, the
next instruction (PC + 1) is pre-fetched. For the device
to wake-up through an interrupt event, the correspond
ing interrupt enable bit must be set (enabled). Wake-up
is regardless of the state of the GIE bit. If the GIE bit is
clear (disabled), the device continues execution at the
instruction after the SLEEP instruction. If the GIE bit is
set (enabled), the device executes the instruction afte
the SLEEP instruction and then branches to the inter
rupt address (0004h). In cases where the execution of
the instruction following SLEEP is not desirable, the
user should have an NOP after the SLEEP instruction.

Jerson