DSP1 not working correctly with example code from lgt_LowPower library

[whyameye]

Testing this example with nano style and normally open pushbutton connected between D2 and GND produces erratic results. Sample output varies. Here is one example of serial output from a fresh run. Comments have been added as lines without datestamps:

17:38:42.458 -> 
17:38:42.458 -> Sleep and external interrupt example started.
17:38:42.562 -> 
17:38:42.562 -> Entering standby mode.
17:38:42.563 -> Apply low signal to wake the MCU.
I pressed and released the button here and got the correct behavior this time:
17:38:45.291 -> Awake!
17:38:45.291 -> MCU was woken up via an external interrupt pin.
17:38:49.288 -> 
17:38:49.288 -> Entering standby mode.
17:38:49.288 -> Apply low signal to wake the MCU.
I pressed and released the button but instead of continuing to execute the code the MCU reset itself:
17:38:50.128 -> 
17:38:52.769 -> Sleep and external interrupt example started.
17:38:52.834 -> 
17:38:52.834 -> Entering standby mode.
17:38:52.897 -> Apply low signal to wake the MCU.

[LaZsolt]

In my opinion the source of the problem is, that the LowPower library sets the watchdog timer for sleep, but does not reset it to the previous state after waking up.
The Low-Power library for ATmega is implemented same way and with same issue. ( https://github.com/rocketscream/Low-Power)

Maybe the solution is to stop WDT immediately after wake up with wdt_disable();

[wollewald]

I tried the sketch as well on a Nano-style board. I pressed the button ~30 times and always got the expected wake-up and not a single reset. There must be something else. However, I have no idea what it could be. @whyameye , how often do you get the reset if you press the button let's say 10 times?

[LaZsolt]

@wollewald
Thanks for your help in finding the error. :)
Is it possibile that the pushbutton is faulty? What is happening if the contacts are bounce faster than the MCU react for the wake up interrupt?

[wollewald]

Yes, maybe it's related to the pushbutton.

@whyameye , to find if the pushbutton is the reason, you could take a second MCU-Board and connect its GND and an I/O pin to the GND and D2 of your Nano style board. Then upload a sketch like this to the second MCU-Board which shall trigger the wake-up:

void setup(){
  pinMode(6, OUTPUT);
  digitalWrite(6, HIGH);
}

void loop(){
  delay(10000);
  digitalWrite(6, LOW);
  delay(50);
  digitalWrite(6, HIGH); 
}

Would be helpful to see whether you still experience resets.

[dwillmore]

I'd second the debounce concern. You have to be extra careful to debounce an input electronically if you're going to use it as some kind of IRQ input to a micro. Any other button makes more sense to debounce in software, but that's not an option for IRQ/wake inputs.

…

On Thu, Apr 18, 2024 at 2:55 PM Wolfgang (Wolle) Ewald < ***@***.***> wrote: Yes, maybe it's related to the pushbutton. @whyameye <https://github.com/whyameye> , to find if the pushbutton is the reason, you could take a second MCU-Board and connect its GND and an I/O pin to the GND and D2 of your Nano style board. Then upload a sketch like this to the second MCU-Board which shall trigger the wake-up: void setup(){ pinMode(6, OUTPUT); digitalWrite(6, HIGH); } void loop(){ delay(10000); digitalWrite(6, LOW); delay(50); digitalWrite(6, HIGH); } Would be helpful to see whether you still experience resets. — Reply to this email directly, view it on GitHub <#317 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACPEX7EV2NPCXYVVLHDTSTTY6AJLLAVCNFSM6AAAAABGNMKGU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRUHE2DONZTGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[whyameye]

First, thanks to all of you for putting some time into helping me with all of this. It is very much appreciated.

Using the code from @wollewald I'm still getting the resets. Here's some grepped output with timestamps:

Fri Apr 19 09:44:40 CDT 2024 Sleep and external interrupt example started.
Fri Apr 19 09:47:51 CDT 2024 Sleep and external interrupt example started.
Fri Apr 19 09:49:11 CDT 2024 Sleep and external interrupt example started.

Still using code from @wollewald and adding wdt_disable(); didn't help:

Fri Apr 19 10:07:06 CDT 2024 Sleep and external interrupt example started.
Fri Apr 19 10:09:47 CDT 2024 Sleep and external interrupt example started.
Fri Apr 19 10:11:48 CDT 2024 Sleep and external interrupt example started.

Photo of my setup and example code with wdt_disable() added are attached. The only changes to the code were that line 20 and line 67 were added to try wdt_disable().

exampleLowPower.zip

[LaZsolt]

I think the error may be related to the way LGT handles the reset vector: #304 (comment)

The lgt_LowPower library using <avr/wdt.h> library for control the WDT. Try to replace this lines to #include <WDT.h>

The logicgreen WDT.h library maybe could handle this issue.

[whyameye]

I'm not sure I totally understood what to try. I tried changing #include <avr/wdt.h> in lgt_LowPower.cpp to #include <WDT.h> and after a few iterations it hangs. For that test I had put the example code was back to original state (wdt_disable() removed) because I couldn't otherwise get it to compile without errors.

[LaZsolt]

I apologise for the many "solution" variation, I'm not going to be able to try it soon, but here is new one:

Inside the ISR put this line wdt_reset();

void anExtISR(void)
{
    intflag = true;
    wdt_reset();
}

I think this will be the only change needed in the original example program. ( standbyExternalInterrupt.ino )

Anyway, that is strange, @wollewald 's try was error free.

[whyameye]

To add that line, I have to either add #include <avr/wdt.h> or #include <WDT.h> to the top of the file.

If I add #include <WDT.h> it resets every time. If I add #include <avr/wdt.h> it hangs after a few iterations.

I'm still using the automated blink-inspired code running on another LGT8Fx as @wollewald recommended to keep any issues with a physical switch out of the equation and to automate the testing. @wollewald did you experience no issues with your automated code running over 15 min?