Snooze library: attachInterrupt wakes up Teensy from hibernate

[darellon]

i recently started playing around with the snooze library. I've noticed that when i attach an interrupt to a pin (not digital.pinMode but attachInterrupt) the interrupt will wake up my Teensy 3.6 from hibernation. Is this intended to be like this? As far as i understood the only pin interrupts that should wake up the Teensy are the ones declared by digital.pinMode but my normal Interrupts seem to wake the Teensy too.

Here is the code i've used:

#include <Snooze.h>
#define but_pin 23
#define but2_pin 10
boolean flag = true;

SnoozeDigital  digital;
SnoozeBlock config_teensy36(digital);
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  digital.pinMode(but2_pin, INPUT_PULLUP, LOW);
  pinMode(but_pin, INPUT_PULLUP);
  attachInterrupt(but_pin, button_int, LOW);
}
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);
  Snooze.hibernate( config_teensy36 );
  digitalWrite(LED_BUILTIN, LOW);
  delay(5000);
  if (flag == true) {
    for (int i = 0; i < 5; i++) {
      digitalWrite(LED_BUILTIN, HIGH);
      delay(200);
      digitalWrite(LED_BUILTIN, LOW);
      delay(200);
    }
    flag = false;
  }
}
void button_int() {
  if (flag == false) {
    flag = true;
  }
}

Setup :
Teensy 3.6
Arduino IDE v1.8.1
Teensyduino v1.35
Snooze v6.2.5

[duff]

So you saying that pin 23 in your example will wake your T3.6 up?

[darellon]

Yes, when i press the button on pin 23 the code enters the for loop and flashes the Led

[defragster]

DUPE POST ... see next ...

[defragster]

Both Pin 23 and 10 are on Port_C:

#define but_pin 23
#define but2_pin 10

AFAIK :: Doing attach Interrupt will interrupt on any pin on that Port_C and Teensy code then validates the firing pin and in the case of this :: attachInterrupt(but_pin, button_int, LOW);

When Pin_23 goes low then isr button_int() would be called.

With Pin_10 on that same Port_C - when it changes the Teensy will have to wake up to see it wasn't but_pin / Pin 23.

Picking a pin not listed on Port_C below should let the Teensy SNOOZE on?

22 PTC 1
23 PTC 2
9 PTC 3
10 PTC 4
13 PTC 5
11 PTC 6
12 PTC 7
35 PTC 8
36 PTC 9
37 PTC 10
38 PTC 11

The schematic shows pin and port associations
There are other posted docs around too.

[darellon]

Does that mean that i could declare a wake up pin that is supported by the snooze library (ex 33 - Port_A)

digital.pinMode(33, INPUT_PULLUP, LOW);

then do a

attachInterrupt(Port_A_pin, isr, LOW)

on another pin on that Port_A and wake up the Teensy through that too?

[defragster]

Duff/others can confirm - If Snooze will wake on a pin then it should be usable - any pin changing on that port would then wake Teensy. If an isr() is attached you will know why it woke.

From your note: any other pin on a shared port results in Teensy waking and returning to loop()?

[duff]

Ok I'll test you example out tomorrow but that should not happen. Does pin 10 in your example wake the Teensy also?

[defragster]

Ok I'll test you example out tomorrow but that should not happen. Does pin 10 in your example wake the Teensy also?

Duff - check my note in post #5 - AFAIK any port pin change will wake to a PJRC_isr()- then established individual pin interrupts are routed when found or ignored - but in any case change to a pin on that port would wake.

This from attachInterrupt() in pins_teensy.c :: attachInterruptVector(IRQ_PORTC, port_C_isr);

Note sure where I read that to recall it. And I don't see the source for port_C_isr to see the individual pin check performed.

[el_supremo]

Just to get rid of one potentially confounding problem, 'flag' should be declared volatile.

volatile boolean flag = true;

Pete

[duff]

defragster, attachInterrupt uses the NVIC, deepSleep and hibernate use the WIC interrupts module.

[defragster]

defragster, attachInterrupt uses the NVIC, deepSleep and hibernate use the WIC interrupts module.

Good to know there are alternate ways. So for a normal AttachInterrupt() I understand correctly the port wide wake?

On hibernate are the normal attachInterrupt() instances disabled then and then these settings are put in place?

SnoozeDigital digital;
SnoozeBlock config_teensy36(digital);

[darellon]

I've just tried some other pins 35 to 38 with attachInterrupt() on Port_C and none of them woke the T3.6. While doing that pulling 23 to ground always woke the T3.6, no matter what pin was declared in attachInterrupt()

edit:
When there is no attachInterrupt() in the code pin 23 doesnt wake up the T

[defragster]

So much for my easy explanation - Duff has more to go on now with post #13.

[manitou]

my tests on T3.6 1.6.12/1.32 latest snooze from github, and added volatile to flag.
pin 10 to ground causes flashes as expected.
with pin 23 and attachinterrupt: grounding 23 causes LED flashes

with pin 22 and attachinterrupt: grounding 22 causes LED flashes. grounding 23 has no effect

with pin 35 and attachinterrupt: grounding 35 causes LED flashes. grounding 23 or 22 has no effect

with pin 21 (D2) and attachinterrupt: grounding 21 causes LED flashes. grounding 23 has no effect


same results with 1.6.13/1.34

? on T3.5, none of the pins above cause the LED to flash (including pin 10)?

on T3.2, pin 10 causes LED flashes. attachinterrupt with pin 23, grounding 23 has no effect


EDIT Re: strange pin 23 behavior
Perhaps a solder problem? pin 23 is next to 3v3

[duff]

I'm going to work on this today with Teensyduino 1.32 beta1 since thats what I have on my puter now. All these different silicones have turned out to be quite different beasts in respect low power. To give an example: some of these chips seem to handle the wakeup interrupts in different ways. So for an instance the T3.2 does not need to enable the LPTMR interrupt in deepSleep or hibernate and just enable the LLWU interrupt to handle the LPTMR registers while the others need both interrupts enabled (LPTMR and LLWU). Then there are details about what order to handle those interrupts and what interrupt to clear the registers in. This in-turn makes for lots of ifdef's that I hate because the code becomes so unreadable even for me that debugging becomes a pain in arse. I'm almost to the point where I will have to separate the files for each Teensy but then I have to refactor the whole library which I would like avoid but I'm afraid its coming to that.

As far as the T3.6 I know some changes where made to the attachInterrupt but my cursory look at the code didn't seem like it would cause any behavior like this? I'm really surprised that it would wake the processor from LLS sleep mode without the LLWU specifically involved but until I actually can see this issue myself I'm holding back any judgment on the root cause of this. It could very well be a bug in my code for the T3.5/6.

[duff]

Ok, there are some problems with the example in post #1

1. flag var needs to be volitale.
2. attachInterrupt -> LOW, should be FALLING.

Using LOW for the normal attachInterrupt will cause that ISR to be called over and over again while its the pin reads LOW, so either declare it FALLING or disable the pin interrupt in the ISR. I'm testing with T3.5 now will test with T3.6 soon.

[duff]

@darellon what speed did you compile at?

[duff]

my tests on T3.6 1.6.12/1.32 latest snooze from github, and added volatile to flag.
pin 10 to ground causes flashes as expected.
with pin 23 and attachinterrupt: grounding 23 causes LED flashes

with pin 22 and attachinterrupt: grounding 22 causes LED flashes. grounding 23 has no effect

with pin 35 and attachinterrupt: grounding 35 causes LED flashes. grounding 23 or 22 has no effect

with pin 21 (D2) and attachinterrupt: grounding 21 causes LED flashes. grounding 23 has no effect


same results with 1.6.13/1.34

? on T3.5, none of the pins above cause the LED to flash (including pin 10)?

on T3.2, pin 10 causes LED flashes. attachinterrupt with pin 23, grounding 23 has no effect


EDIT Re: strange pin 23 behavior
Perhaps a solder problem? pin 23 is next to 3v3

I'm not seeing this can post an example that shows this?

[manitou]

I used the sketch above but adding volatile to flag and per your suggestion FALLING in attachInterrupt(). T3.6@180mhz still behaves as i described: pin 10 to GND causes flashing, as does pin 23 to GND. Using clone of https://github.com/duff2013/Snooze in my libraries/, and am pretty sure IDE is using that lib.

and T3.5 @120mhz still has no flashing from either 10 or 23 to GND
ubuntu 1.6.13/1.34

[duff]

I used the sketch above but adding volatile to flag and per your suggestion FALLING in attachInterrupt(). T3.6@180mhz still behaves as i described: pin 10 to GND causes flashing, as does pin 23 to GND. Using clone of https://github.com/duff2013/Snooze in my libraries/, and am pretty sure IDE is using that lib.

So there are issues at speeds over 96MHz on the T3.6 because for some reason the USB seems to be on even though its not working, I have solution figured out but need to still implement it. As far as that example I didn't see any pin using the core attachInterrupt waking the Teensy with my fixes to the example posted in post #1? I'll do some more tests today but unless it's a hardware issue I don't know how it possibly could wake the Teensy without configuring the LLWU pin wakeup and especially pin 23 which is not wakeup pin for LLS/VLLS (deepSleep/hibernate).

[manitou]

Just to be sure I removed the snooze lib from the IDE, so IDE will use my latest clone. No change in my reported results for T3.5 and T3.6

T3.6 at 96mhz, only pin 10 causes LED flashing

T3.5 @96mhz: no flashing from pin 10 or 23

[duff]

Just to be sure I removed the snooze lib from the IDE, so IDE will use my latest clone. No change in my reported results for T3.5 and T3.6

T3.6 at 96mhz, only pin 10 causes LED flashing

T3.5 @96mhz: no flashing from pin 10 or 23

This is weird, I see what you're talking about but only at speeds greater than 120 MHz, seems with my T3.6 that any pin configured with attachInterrupt will wake the Teensy up even if I use dummy driver in that nothing configures it to wakeup

[duff]

I think High Speed Run Mode is causing the problem.

[duff]

Should be fixed now, please download v6.2.6 here and let me know?