I2C error on pytrack with LoPy
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...') gc.enable() pycom.heartbeat(False) pycom.rgbled(0x000008) py = Pytrack() time.sleep(2) th = DTH('P11',1) time.sleep(2) 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 py.setup_sleep(sendIntervall/10) py.go_to_sleep(False)
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.
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.
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