HIDoff wakeup reason (in particular, which GPIO interrupt?)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

My application uses HIDoff to save power and wakes up from one of several GPIO interrupts.

Is there any way to tell which line generated the interrupt that cause the wakeup?

Is there a way to tell whether the wakeup was due to an interrupt, or due to some other cause (such as powerup)?

0 Likes
1 Solution
Anonymous
Not applicable

Try to use gpio_getPinInterruptStatus() or gpio_getPortInterruptStatus().

If it is a timed wake up, the mia_isResetReasonPor() will return false and gpio_getPinInterruptStatus(GPIO_PIN_P39/16, GPIO_PIN_P39%16) will return 1.

Otherwise, the wake up source should be some other GPIO (it  mia_isResetReasonPor() return false).

gpio_getPinInterruptStatus() or gpio_getPortInterruptStatus should indicate the pin number.

Hope it helps.

View solution in original post

5 Replies
ShawnA_01
Employee
Employee
10 questions asked 5 comments on KBA First comment on KBA

I dug through some old emails/forum posts and found these.  Hope it helps.

Re: How can I get bcm20732s reset reason?

Pertinent text:  The only reset reasons the 2073x chips currently provide are power-on-reset (use mia_isResetReasonPor() ) and timed wake (use mia_isResetReasonTimedWake() -  when the device wakes from deep sleep due to the wake timer expiring).


This other thread talks about identifying the Pin source:

Re: how to identify GPIO interrupt source pin?

0 Likes

Thanks, Shawn!

I’ll try those.

0 Likes

santol

After looking at these, I think the answer to my question is "No".

Based on my tests, upon waking up from HIDoff because of a GPIO interrupt, the system wakes up but the interrupt handler is not actually called.  There is no other way to tell that the wake up was due to a GPIO interrupt.  So, unless the condition that triggered the wakeup is still present (i.e. a level triggered interrupt and the level is still high after boot-up), it's not possible to respond to the stimulus.

Is this interpretation correct?

0 Likes
Anonymous
Not applicable

Try to use gpio_getPinInterruptStatus() or gpio_getPortInterruptStatus().

If it is a timed wake up, the mia_isResetReasonPor() will return false and gpio_getPinInterruptStatus(GPIO_PIN_P39/16, GPIO_PIN_P39%16) will return 1.

Otherwise, the wake up source should be some other GPIO (it  mia_isResetReasonPor() return false).

gpio_getPinInterruptStatus() or gpio_getPortInterruptStatus should indicate the pin number.

Hope it helps.

Thanks for the help Roger.

0 Likes