I2C error on pytrack with LoPy

  • Hi,

    I am running a pytrack with a LoPy 1.19.0b4 LittleFS with a DHT-22 on Pin 11 and a switch on P10.
    The scripts run fine, when I upload them. After a few deepsleeps the LoPy stops with

    Traceback (most recent call last):
      File "main.py", line 24, in <module>
      File "lib\pytrack.py", line 8, in __init__
      File "lib\pycoproc.py", line 96, in __init__
      File "lib\pycoproc.py", line 151, in poke_memory
      File "lib\pycoproc.py", line 112, in _write
    OSError: I2C bus error


    Traceback (most recent call last):
      File "main.py", line 61, in <module>
      File "lib\pytrack.py", line 8, in __init__
      File "lib\pycoproc.py", line 102, in __init__
      File "lib\pycoproc.py", line 164, in set_bits_in_memory
      File "lib\pycoproc.py", line 154, in magic_write_read
      File "lib\pycoproc.py", line 112, in _write
    OSError: I2C bus error

    depending on the positon of py = Pytrack()
    actually it is:

    from network import LoRa
    from network import WLAN
    import socket
    import time
    import pycom
    import utime
    from machine import RTC
    from machine import SD
    from machine import Timer
    from machine import Pin
    from dth import DTH
    import dth
    import gc
    import sfGPS
    from pytrack import Pytrack
    print('sfGPS and DTH startup...')
    py = Pytrack()
    th = DTH('P11',1)
    print('DTH-22 on Pin11 initilized')

    So it is one of the topmost calls and shall not interfere with other I2C read/writes to the GPS and DTH-22. I read GPS data continiously in a thread.

    beside main.py all other files are cross compiled to *.mpy

    Placing the call next to the top of main.py and moving the pycoproc.mpy into the subfolder lib, made nearly stable.
    But it will still crash after a couple of dozen sleeps:

    sendIntervall = 600

    Can someone give me advice how to get rid of this error or how I can reproduce it without bad luck?
    Can I detect a brown out by software?

  • @crumble thanks for the extra info. Ill pass it along.

  • @paul-thornton

    waiting for 4500ms seems to be stable over night.

    The time is acceptable for a GPS system which needs some time until it gets a fix. But it is inacceptable how we shall find the correct timings.

    Please do not work on a quick fix for this. We need a clean solution working with every module of Pycom.

    F*k: Never tell someone it's running. Now I need to wait additional 500ms. Moved the GPS to the window. Maybe the L76 behaves different if it receives signals.

  • @crumble Thanks for the fast response. Ill update you as soon as I have something.

  • @paul-thornton

    It will happen with any version of your released firmware. It will happen depending on the firmware.

    With 1.19 it occurs not that often directly on startup. There are really good chances to run into this after sleeping of 750ms.

    With 1.20 I run into this directly after startup up to 2000ms. Sometimes up to 3500ms.

    I noticed a strange behaviour. using time.sleep(1) instead of utime.sleep_ms(2000) seems to fail not that often. But this maybe only bad luck while testing ;)

    LoPy runs now on 1.20 and pytrack on 0.8

    I grumbled about this on your release message of version 1.20 as well. But with some code changes on my side.

  • This is actually a bug that Ive encountered a few times lately and am currently trying to track down a root cause.
    Out of curiosity.

    Do you have a second LoPy you can try this on?. I am unable to reproduce it on the one I have.

    Could you also confirm the same board that experiences the issue still happens on the latest release candidate: https://forum.pycom.io/topic/4099/new-firmware-release-candidate-v1-20-0-rc0


Log in to reply

Pycom on Twitter