Pytrack and.or Deep Sleep break terminal output ?

  • Guy,

    I'm trying a new tracker code with Lopy and Pytrack + sleep and wake interrupt, but I'm suck with console output problem, so I restarted from library example code accelerometer_wake to reproduce the issue.

    I modified a little to have some print and wait to be able to connect terminal (because deep sleep shut down usb device seen in windows)

    Here the code

    import machine 
    from machine import UART
    from pytrack import Pytrack
    from LIS2HH12 import LIS2HH12
    from network import Bluetooth
    from network import WLAN
    import pycom
    import time
    import os
    uart = UART(0, 115200)
    # Wait for terminal to connect
    print("Wait for sync ", end='')
    for x in range(0, 10):
        print("#", end='')
    print(" OK!", flush=True)
    rst = machine.reset_cause()
    print("starting, Reset=", rst)
    print("stage 1", flush=True)
    py = Pytrack()
    print("stage 2", flush=True)
    print("Wakeup reason: ", flush=True)
    print("; Aproximate sleep remaining: ", flush=True)
    print(" sec", flush=True)
    # enable wakeup source from INT pin
    # enable activity and also inactivity interrupts, using the default callback handler
    py.setup_int_wake_up(True, True)
    acc = LIS2HH12()
    # enable the activity/inactivity interrupts
    # set the accelereation threshold to 2000mG (2G) and the min duration to 200ms
    acc.enable_activity_interrupt(2000, 200)
    # wait 15 second before deep sleep to be able to upload 
    print("Wait for update ", end='', flush=True)
    for x in range(0, 15):
        print(".", end='', flush=True)
    print(" OK!", flush=True)
    # go to sleep for 30 seconds max if no accelerometer interrupt happens
    print("Go to deep sleep...")

    The fact is that the program works pretty fine (I know this because 15 seconds after printing stage 1 the device goes to deep sleep (windows beep) and wake up after 30s of deep sleep (windows beep agin and device shows up in device manager), Then I reconnect and got display until stage 1 again

    Here the output of terminal (I manually disconnect when entering deep sleep and reconnect after deep sleep wake)


    What I am missing ? Looks like some system call break the dupterm, I tried to reset console after stage 1 but same things.

    py = Pytrack()
    uart = UART(0, 115200)
    print("stage 2", flush=True)

    I'm using latest firmware as today 1.17.3.b1 and latest pymakr but also tried with another terminal, same thing

    Any idea of what's going wrong there ?

  • @jcaron I think I got it

    The calibrate_rtc() in library pycoproc break the console output, if I comment this call from get_sleep_remaining() No problem

    Connecting on COM24...
    # OK!
    starting, Reset= 0
    stage 1
    stage 2
    Wakeup reason:
    ; Aproximate sleep remaining:
    stage 4
    Wait for update .............

    may be the deal is out there

    def calibrate_rtc(self):
            # the 1.024 factor is because the PIC LF operates at 31 KHz
            # WDT has a frequency divider to generate 1 ms
            # and then there is a binary prescaler, e.g., 1, 2, 4 ... 512, 1024 ms
            # hence the need for the constant
            self._write(bytes([CMD_CALIBRATE]), wait=False)
            Pin('P21', mode=Pin.IN)
            pulses = pycom.pulses_get('P21', 100)
            self.i2c.init(mode=I2C.MASTER, pins=(self.sda, self.scl))
            idx = 0

  • @jcaron Absolutely, thanks for pointing this out

    I created a

    from machine import UART
    import os
    uart = UART(0, 115200)

    of course removed this line from

    it's far better but console still looks up after call to py.get_sleep_remaining()


  • I believe there is a default which already contains the dupterm stuff on a fresh module, not sure if having that both in the and the may be an issue?

  • I took a new Fresh Lopy / Pytrack, updated firmware on both devices and flashed same code

    Same result


  • @jcaron I do not have for this sample issue (I wanted the sample to be simple)

    has suggested, I've done the changes, same thing.


  • @charly86 I believe so, yes. What do you have in your Have you tried clearing the filesystem completely and re-uploading all the files? Sometimes you end up with old files which result in weird stuff like this.

    Have you tried adding a pause just after the stage 1 print + another print before instantiating the Pytrack object? Just to see if it's timing-related or directly related to the connection to the Pytrack...

  • @jcaron sorry forgot to mention, it's 0.0.8, looks like the latest?

  • Is the Pytrack firmware upgraded to the latest version?

Pycom on Twitter