Serial.begin(115200);
–attach usb cable and verify strings sent–
Red led start flashing dimly
Serial.end();
LowPower.attachInterruptWakeup(5, nullptr, FALLING);
LowPower.deepSleep();
–no wake on pin 5 going low–
Red led flashing dimly
i dont think red led flashing is a good sign… sounds like it is still in bootloader mode the programming did not stick
It is running code and using that to go to sleep but cannot wake again, I suspect the pin change interrupt is somehow disabled.
Try this
LowPower.attachInterruptWakeup(PC5, nullptr, FALLING);
1 Like
Hi there,
If I might Add…
If you use:
LowPower.attachInterruptWakeup(WAKEUP_PIN, nullptr, FALLING);
this tells the library “I don’t need any function to run when the wake-up occurs.” This may be acceptable in some cases if you don’t need to execute any code on wake-up beyond the inherent reset that happens with deep sleep.
However, if you plan to run some code on wake-up (or if the library expects a valid function pointer), you should supply a callback function (for example, a function named wakeUp):
LowPower.attachInterruptWakeup(WAKEUP_PIN, wakeUp, FALLING);
In our examples, we defined a simple wakeUp() function—even if it’s empty—to make sure a valid pointer is passed. This can help avoid potential issues and makes it clear that an interrupt event is expected.
using nullptr isn’t inherently “bad,” but you need to ensure that it’s acceptable for your use case and supported by the library. If the library expects a function pointer for proper wake-up behavior, replacing nullptr with a valid callback (even an empty one) is the right approach. (this is a Pre Brick Scenario) Use it with the wrong PCx and it will go upside down, code runs but no more flashing is possible (PC0=GND) to fix.
any way nullptr is a keyword introduced in C++11 that represents a null pointer—it literally means “no pointer” or “nothing.” In our context, passing nullptr to a function that expects a pointer indicates that you’re not providing a callback function.
Kinda lazy example they provided in the WiKi . LOL , IMO. 
GL 
PJ 
Hi,
I tried using the callback but it didn’t seem to work, in the setup function I use LowPower.wokeUpFromDeepSleep() to recover the previous state. This issue only happens when using Serial.begin and connecting and then disconnecting USB. Without Serial.begin it works fine. After a power cycle with Serial.begin but without USB connected at all it also works fine. Plugging in USB makes the red LED flash dimly and then the wake failure becomes an issue but only after unplugging USB. I suspect the USB stack.
This is a project I’m helping a friend with, I’ve been working as an embedded C developer for 8 years doing board bringups and advising schematic design. Documentation can’t always be trusted…
1 Like
I just put a print in the callback, it does not get called at all it seems, or USB is non functional at that point ?
Hi there,
Yes I had the same experience, certain power modes i think do not release the port.?? or at least ALL the way…
GL PJ
Hi,
I did try add Serial.end() before going to sleep, that didn’t help either, don’t have the time right now to go into the USB stack rabbithole. In my experience USB becomes really unhappy when sending data while the cable is not connected.
1 Like
Which XIAO are you testing with?
I used MG24 with no radio
OK - I’ve been testing with that.
When using Serial over USB there’s not need to “end” it.
If not using USB (eg using battery pads); just don’t do a Serial.begin();
The nullptr is correct, but doesn’t matter as DeepSleep replaces the pointer parameter with nullptr anyway. A wakeup isn’t called with DeepSleep, just a device reset.
The very dim charge led is “normal”.
What other code have you added?
Currently I’m only using the serial port for debugging but now cannot use it as a terminal interface with a battery.
I did add a custom 2812 library that enables DWT->CYCCNT, the ezWS2812 library didn’t have it running unless a debugger was connected…
//enable debug cycle counter
volatile unsigned int *DWT_LAR = (volatile unsigned int *)0xE0001FB0;
volatile unsigned int *SCB_DEMCR = (volatile unsigned int *)0xE000EDFC;
*DWT_LAR = 0xC5ACCE55;
*SCB_DEMCR |= 0x01000000;
*DWT_LAR = 0xC5ACCE55;
DWT->CTRL |= 1;
Can’t say I’ve used raw code to set the cycle counter!
I use this…
void sl_cycle_counter_enable(void)
{
CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
ITM->LAR = 0xc5acce55;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
}
I shall leave the intricacies of ezWS2812 up to you
I just use SPI for WS2812 on MG2x - seems OK - though haven’t tried using with Arduino code.
1 Like
I tested the ezWS2812gpio library after removing the USB/Serial and it worked fine with the code from above (it’s using the debug cycle count).
It’s also working with DeepSleep modes.
I prefer your cycle counter code, thanks.
Does the CMSIS-DAP do anything over SWD when powered up over USB ? This could potentially be a cause of this issue.
Is the SAMD11_RX getting power in the the ATSAM from the MG24 TX pin ? And then bleeding power out via the regulator to the charger IC ? I measure 3v51 on the Vin pin before connecting USB and 3v47 after disconnecting.
LED is flashing bright orange while connected and dim after disconnecting, it goes off after a power cycle. Without Serial the Vin pin measures the same as the battery.
So the MG24 TX will need to be open collector with a pullup to prevent this issue. Connecting U10 to VIN instead of VBUS might help but might also mess up USB state machines.
Not sure… It shouldn’t until OpenOCD has started.
I’ve been trying to figure out power usage when in Sleep mode (EM2 is about 80uA).
Deep Sleep (EM4) is running at ~1uA so I think that’s OK. But EM2 is much higher so I’ve been looking at possible GPIO settings that could cause that.
The MG24_TX (and RX) seemed the best was when disabled.
I’ll look at the power again. Seems the Sam_D11 is still powered when USB/Serial is removed?
I added just a battery to a MG24 for testing and get 6.3mA while running my code and 44uA in deep Sleep, connecting USB runs -26mA into the battery which is fully charged.
After Serial.begin() it is as follows 17.8mA running and 1.2 - 2.2mA deepSleep.
After a power cycle it is 17.2mA and 166uA and the USB unplugged.
Interestingly it is 17.2mA and 924uA while the USB cable is plugged in but not connected to the computer side. Unlugging the cable still have it at 911uA, seems a power cycle is needed to drop down to 166… weird.
On the other device I’m using 2x26 WS2813 connected do pin D6+D7 and 2 buttons on D4+D5 and mosfet enable → 4k7 → D8 since the 2813 draws about 50mA at RGB 0,0,0. I’m getting 120mA at RGB 128,0,0 and 177uA in deepsleep.
