Sign in

username:

password:



Not a member?

Search LPC900_users



Search tips

Subscribe to LPC900_users



Ads

Discussion Groups

Discussion Groups | LPC900 | LPC935 total power down problem

Find help, specifications and source code for the LPC900. The LPC900 challenges Microchip and AVR based on the worlds most popular 8-bit architecture the 80C51. With a 2-clock core the LPC900 series is a high performance, very flexible and low cost 8-bit microcontroller family. Designers using or interested in these devices are encouraged to share their know-how and ask questions.

LPC935 total power down problem - geejee_lpc - Apr 10 14:13:05 2006

Hi,

Iam using the LPC935 and switch it to total power down modus to
conserve battery power. DIVM=0 in my application. I am using the KBI
interrupt to wake up the controller.

Now when there is an interrupt active a few micro seconds before I
switch to power down modus (PCON=0x03), the device enters power down
modus and never wakes up. With an oscilloscope I can see that the
keypad ISR is entered almost immediately and probabely just before the
instruction PCOM=0x03 is executed.

Has anyone similar experiences and is there a workaround for this
problem?

Regards,
Gertjan



(You need to be a member of LPC900_users -- send a blank email to LPC900_users-subscribe@yahoogroups.com )


Re: LPC935 total power down problem - phb_miller - Apr 12 18:59:39 2006

Hi there,

> Now when there is an interrupt active a few micro seconds before I
> switch to power down modus (PCON=0x03), the device enters power down
> modus and never wakes up. With an oscilloscope I can see that the
> keypad ISR is entered almost immediately and probabely just before
the
> instruction PCOM=0x03 is executed.

I suspect that you have not cleared the KBI interrupt correctly, or you
are returning with another KBI already pending. If so then the
interrupt system will always ensure that one instruction of the main
program is executed before the interrupt is repsonded to.

So if the device 'thinks' it is in an interrupted state when you enter
TPD then it would require a higher priority interrupt to restart it.

My suggestion is to ensure that the last step of your KBI ISR is to
clear the pending interrupt flag.

PM



(You need to be a member of LPC900_users -- send a blank email to LPC900_users-subscribe@yahoogroups.com )

Re: LPC935 total power down problem - geejee_lpc - Apr 25 12:00:11 2006

Thanks PM, this works! Clearing the KBI flag was the semi-last
instruction of my ISR.

By the way, how did you know that the interrupt system ensures that
at least one instruction is executed prior to jumping to ISR's? Is
this documented somewhere?

Regards,
Gertjan

--- In l...@yahoogroups.com, "phb_miller"
wrote:
>
> Hi there,
>
> > Now when there is an interrupt active a few micro seconds before
I
> > switch to power down modus (PCON=0x03), the device enters power
down
> > modus and never wakes up. With an oscilloscope I can see that the
> > keypad ISR is entered almost immediately and probabely just
before
> the
> > instruction PCOM=0x03 is executed.
>
> I suspect that you have not cleared the KBI interrupt correctly, or
you
> are returning with another KBI already pending. If so then the
> interrupt system will always ensure that one instruction of the
main
> program is executed before the interrupt is repsonded to.
>
> So if the device 'thinks' it is in an interrupted state when you
enter
> TPD then it would require a higher priority interrupt to restart it.
>
> My suggestion is to ensure that the last step of your KBI ISR is to
> clear the pending interrupt flag.
>
> PM
>



(You need to be a member of LPC900_users -- send a blank email to LPC900_users-subscribe@yahoogroups.com )

Re: LPC935 total power down problem - phb_miller - Apr 26 19:47:18 2006

Hi there Gertan,

> By the way, how did you know that the interrupt system ensures that
> at least one instruction is executed prior to jumping to ISR's? Is
> this documented somewhere?

Had to search a bit but located the comment in the Family Hardware
Description (Philips IC20, 1995) on how interrupts are handled. It
states that the polling cycle will not cause a LCALL if:
1) an interrupt of equal or higher priority is already in progress;

2) the current polling cycle is not the final cycle in the execution of
an instruction already in progress;

3) the instruction in progress is RETI or a write to IE or IP (or their
extended cousins) registers.

The inference of (3) is that no polling occurs during the RETI and so
one complete instruction has to occur before another vector can take
place.

The description goes into reasonable depth and explains where within a
cycle the polling actually takes place. Simply put it is S5P2 of the
last machine cycle before the next instruction opcode fetch.

PM



(You need to be a member of LPC900_users -- send a blank email to LPC900_users-subscribe@yahoogroups.com )