Pytrack get_wake_reason: detect power on

  • Hi,
    I am working with a Pytrack and a Fipy, and I must detect when the board is powered-on.

    When I get the pytrack.get_wake_reason, I get correct values when awaken by button, accelerometer and timer after a pytrack.go_to_sleep().
    However, after a power down (unplug the USB), the wake reason is kept from the last powerdown (WAKE_REASON_ACCELEROMETER for example) for a short persiod, and after a long disconnection (like >1 hour), the pytrack.get_wake_reason method gives me strange values, like 51 (0b110011).

    How can I detect when the board is powered-on ?


  • @fstaine
    WAKE_REASON_INT_PIN: can be generated from PIC_RC1(pin6 on External IO Header)

    <later edit:> Please take a look here function pytrack.setup_int_pin_wake_up([rising_edge = True]).

  • Just for further references, there a workaround solution with code here:

    Mainly it's:

    wake = py.get_wake_reason()
    print("Waked by ", end='')
    # display the wake reason code
    if wake == 1:
    elif wake == 2:
    elif wake == 4:
    elif wake == 8:
        print("Interrupt Pin")
        print("No Wake")

  • hi @catalin

    I tried with the given firmware:

    • I get correct values for Accelerometer (1), push button (2) and timer (4) on get_wake_reason() (as before)
    • I get 0 from get_wake_reason() after a power on (Yay !)
    • I don't know how to test WAKE_REASON_INT_PIN...

    Concerning get_sleep_remaining(), the board never returns when I call the method from the serial REPL (in fact, calibrate_rtc() blocks at self._write(bytes([CMD_CALIBRATE]), wait=False) )

    When I do from a scipt, I get the correct values (Havn't tested the values when a timer wasn't set with the previous firmware though...)

    Thank's a lot for the fix ! I go change my ugly hack in my code :)

  • hi @fstaine,

    Could you test the attached pytrack firmware version; if the board is powered on, it should have both the get_wake_reason() and get_sleep_remaining() reset to zero. Is this behaviour ok?


  • hi @fstaine, I trying to investigate this, I see there is an inconsistency.

Pycom on Twitter