How do you configure a low-true GPIO wakeup interrupt.

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

cross mob
EdHa_4455331
Level 5
Level 5
25 replies posted 25 sign-ins 10 replies posted

My deep-sleep wake-up interrupt that comes in through a GPIO pin that is low- true (wake up when the input value goes to 0). I would have thought this should do it.

EdHa_4455331_0-1644522682444.png

But with the inverter in place, the system assigns DeepSleepWakeUp to an interrupt that does not operate in deep sleep.  And there doesn't seem to be any way to override this assignment. 

So, can anybody tell me how to do this?

Thanks,

Ed H.

0 Likes
1 Solution
EdHa_4455331
Level 5
Level 5
25 replies posted 25 sign-ins 10 replies posted

Well, I now understand why that configuration doesn't work (read the flaming PDL documentation). So I switched to:

EdHa_4455331_0-1644542924647.png

The ExpanderInterrupt pin is configured to throw an GPIO expander interrupt on a falling input edge. DeepSleepWakeup is configured for auto-select trigger, and expander interrupt is configured for level.

This should give me a falling edge (on the input pin) triggered interrupt to wake up the system, and also a level sensitive interrupt to deal with the fact that the input signal is a composite of many interrupts that can go off asynchronously.

So the sequence of events should go as follows:

1. The system is in deep sleep.

2. A falling edge occurs on the input pin.

3. The falling edge should generate a DeepSleepWakeup, which wakes up the system.

4. Now that the system is awake, the (still) low signal on the input pin can generate a level-sensitive expander interrupt.

5. After handling and clearing the interrupts, the system goes back into deep sleep.

Now, what is now driving me crazy is that this works once and only once. When the system goes back into a deep sleep, subsequent falling edges on the input pin won't wake up the system.

Additionally, if I just put the system into sleep instead of deep sleep, it works like I want it to. Unfortunately, the standby current is way to high in ordinary sleep for my application. Also, if I keep the deep sleep instruction but use the debugger, it works fine (which isn't a big surprise because the system won't go into deep sleep with the debugger connected).

It could still be a software bug, but that seems to be heavily discounted by the fact that the system only misbehaves if I use deep sleep (as I said, sleep works fine). So that leaves me with perhaps some unknown incompatibility between my configuration and what is really getting configured in hardware.

If anyone has any insight to share it would be most appreciated.

Thanks,

Ed H.

View solution in original post

0 Likes
1 Reply
EdHa_4455331
Level 5
Level 5
25 replies posted 25 sign-ins 10 replies posted

Well, I now understand why that configuration doesn't work (read the flaming PDL documentation). So I switched to:

EdHa_4455331_0-1644542924647.png

The ExpanderInterrupt pin is configured to throw an GPIO expander interrupt on a falling input edge. DeepSleepWakeup is configured for auto-select trigger, and expander interrupt is configured for level.

This should give me a falling edge (on the input pin) triggered interrupt to wake up the system, and also a level sensitive interrupt to deal with the fact that the input signal is a composite of many interrupts that can go off asynchronously.

So the sequence of events should go as follows:

1. The system is in deep sleep.

2. A falling edge occurs on the input pin.

3. The falling edge should generate a DeepSleepWakeup, which wakes up the system.

4. Now that the system is awake, the (still) low signal on the input pin can generate a level-sensitive expander interrupt.

5. After handling and clearing the interrupts, the system goes back into deep sleep.

Now, what is now driving me crazy is that this works once and only once. When the system goes back into a deep sleep, subsequent falling edges on the input pin won't wake up the system.

Additionally, if I just put the system into sleep instead of deep sleep, it works like I want it to. Unfortunately, the standby current is way to high in ordinary sleep for my application. Also, if I keep the deep sleep instruction but use the debugger, it works fine (which isn't a big surprise because the system won't go into deep sleep with the debugger connected).

It could still be a software bug, but that seems to be heavily discounted by the fact that the system only misbehaves if I use deep sleep (as I said, sleep works fine). So that leaves me with perhaps some unknown incompatibility between my configuration and what is really getting configured in hardware.

If anyone has any insight to share it would be most appreciated.

Thanks,

Ed H.

0 Likes