Pyboard machine.deepsleep not waking from RTC, PA0, PC13 when other ICs have power

[Dugite]

I have developed a data logger based on the Pyboard 1.1 which is running Micropython 1.11 as shown below:

Capture.JPG (25.53 KiB) Viewed 2997 times

It has the following other ICs on the board which are power switched to save power during deepsleep mode:

• SPI Digital IO;

• SPI ADC;

• SPI Temperature;

• Serial ICs;

• Accelerometer.

I have setup pins PA0 and PC13 to wake the board from deepsleep on a rising edge as follows:

stm.mem32[stm.PWR + stm.PWR_CSR] |= 1 << 8 # enable WKUP pin on PA0.
stm.mem32[stm.RTC + stm.RTC_TAFCR] |= 1 << 0 # Tamper 1 detection enabled PC13.
machine.deepsleep()

The problem I am having is as follows:

• If I switch off all of the other ICs in deepsleep mode, when I toggle the PA0 or PC13 pins, the microcontroller immediately wakes up as expected, including from the RTC wakeup;

• If I keep the power enabled for the other ICs and then enter deepsleep mode the microcontroller will not wake up from either the RTC or PA0 or PC13.

Does someone know what could be stopping deepsleep wakeup from working when the other ICs have power applied? Any comments or help with this would be much appreciated

[ghayne]

Could it be that when the other IC's are powered that they are preventing wake from deep sleep by holding Pyboard inputs high or low somehow? Just a quick idea.

EDIT: Just found this:
https://github.com/micropython/micropython/issues/3834

[Dugite]

@ghayne

PA0 is being pulled high by the SPI IO interrupt pin when in machine.deepsleep mode, but not during pyb.wfi. I am not sure what is going on here yet, but will investigate and respond when fixed

[Dugite]

The problem ended up being the MCP23S17 chip has an IO-RESET pin which was not pulled high (resets on low). This meant that in deep sleep, the STM32 was no longer controlling this pin so it went low putting the chip into reset which was preventing PA0 from triggered the wake up interrupt.

The fix was to use a 100k pull-up resisitor on IO-RESET which fixed the problem.

[ghayne]

Glad that you sorted it.