I2C read error on new hardware, works with old version
-
I have an issue with I2C sensors that seems hardware related. I have SI-7021 sensors that work fine on boards with a GPy version V1.0r but when I run the same code on V1.2 it will not work, I get a sensor read error. I run P10 as SDA and P11 as SCL. Tried numerous sensors and it only works with the old hardware revision. Anyone that knows what needs to be updated, any is highly appreciated
-
@robert-hh Thanks, no have not tried that one, I will have a look but I doubt I have the knowledge to understand how to use it I am afraid (but I will ask our developer for guidance). I agree, the GPys are not the issue but my process of updating halts. I doubt it is a hardware issue, but something in the update process with the pycom firmware update tool does not rock. CLI sort of worked, but one device came out as E (31) esp_image: image at 0x10000 has invalid magic byte in VSCode, so I do not dare to continue with VSCode.
-
@Don-iot I doubt that the reason is the GPYs. Because at that stage only the ESP32 is involved and just a few pins, which are straight connected to the ESP32. Did you try using the pyupgrade.py tool from the git repository (see my link below). Since I use home-built firmware, that's he one I run. The difference to he packaged version of the -cli updater is, that it's still python source.
-
@robert-hh Well the only successful board at the moment is my own board as well with TTL to USB converter and lowered speed to 115200 bps. That one is the one that seems to work. I have the P2 grounded and press reset. I have two errors Failed to connect to ESP32: Timed out waiting for packet header and Failed to write compressed data to flash after Seq 0 (result was C100). And I get this error over and over again, I am now counting seven new Pycom GPys on my desk with same result.
-
@Don-iot I had that sometimes when the UART speed was too high. You could try to reduce the speed to 460800 baud.
You could also try to manually switch to boot mode by connecting P2 to GND and pushing reset.I do not have a Pycom expansion board 3.x here, just the sensor boards and an expansion board 2.1. And I do not use them. Instead I use my own expansion board, based on a FT232 and the espressif bootloader mechanism. The FT232 uses a lot of current (~15mA), so it's not good for low power testing. But is it robust in daily use, being simple and dumb.
-
@robert-hh Thanks for your support, I am currently trying my brand new expansion boards on a pc and on a mac with different cables and five different new GPys straight out of the box, and I clearly need another solution.
Most of the devices that we are able to reach report back "Failed to connect to ESP32: Timed out waiting for packet header" -this is both CLI and Pycom Firmware update. Those that we successfully can erase via CLI can not be updated with GPy-1.20.2.r1.tar.gz from my local file via CLI. Failed to write compressed data to flash after seq 12 (result was C100) -what is causing this for me over and over again, I am getting desperate to find a solution.
I will look at your options but again, this seems to be related to something with the Pycom firmware or hardware, as it just keeps repeating itself. (If it is there anyone that knows what this error is and knows the cure, well feel free to reach out, thanks in advance) and again thanks for your awesome support.
!
-
@Don-iot You can always use esptool.py for a full flash erase, which will definitely erase all of the flash.
pycom-fwtool-cli erase_all also claims to erase everything, but I have more trust in esptool.py
pycom-fwtool-cli could be a packaged version updater.py from https://github.com/pycom/pycom-micropython-sigfox/tree/Dev/esp32/tools/fw_updater, which place also holds a copy of esptool.py
-
@Gijs Thanks, yes I can confirm this was solved by updating firmware. The main issue I think was, and to some extent it still is an issue for me, is that our preconfiguration process before we apply our own code does not always work. So any thoughts on the process would be highly appreciated. So what we do is that we
a) take the new devices out from the box, using Pycom Firmware updater we erase everything and format everything we can to start fresh.
b) we take these devices that we have erased and should be at the same starting point and we apply the exact same code except certificates and device ID that are device specific.Now to the problems we are having with step a. When we use the firmware updater, some of the devices gets an ESP-error and the process is stopped. The devices can not be formatted. We can in some cases upload via CLI but as far as I understand, that never formats the device (using /Applications/Pycom\ Firmware\ Update.app/Contents/Resources/pycom-fwtool-cli -p /dev/cu.usbmodemPy8888f1 flash --tar /Users/and so on).
In some threads here, I have read that the expansion boards are sometimes the issue. I just purchased two new, but that does not seem to solve it. Another suggestion is to use a TTL to USB adapter and our own board. I have that option, but even at lower data speeds this method fails with the same devices that fails with the expansionboard. It works on some, but these work with the expansion board as well.
Of the devices that qualifies to step b some can not initiate LTE, one device today that is new could not connect to the LTE-network (see another thread on that topic). This seems to be the issue over and over again. There is a scaring number of devices that fail in a), today I had three with ESP errors from new devices.
What I am trying to achieve here is not that complex one would think. I need a method to get new devices shipped from Pycom formatted and reset to the same firmware and then uploaded with our code in VScode. How can we get a smooth workflow? I have to configure some 80 devices this month and I have to get a method where each device will take a few minutes to configure, instead of the case now where new units takes hours of problem solving.
Long post, but it would be great to get your insights on how to optimise our process.
-
Im sorry, can you confirm for me they are all running 1.20.2.r0? We tested the I2C with various firmwares today (not using the exact sensor you have) and for us it worked fine all along.
Now I do not think it is an issue with the firmware nor hardware, can you perhaps elaborate on the code you are using?I believe you are also in email contact with my colleagues who provided some feedback as well
Best,
Gijs
-
Ok, thanks so much, then I understand. I currently only have four GPys that I can not format via the firmware updater tool, I get read errors from all of these. I was hoping for a solution via CLI.
-
The NVS and CONFIG formatting I was refering to is an option in the firmware updater tool (enable advanced settings and it will showup in the next page) but it should be the same method as you are refering to! :-)
Gijs
-
@Gijs Thanks for proposal. I was looking at formatting NVS and I assume this is what your are referring to? NVS formatting but the config partition, I can not really find documentation?
-
Hi,
Please let me know if you are running the same firmware version on the GPy V1.0r and V1.2 (also make sure the CONFIG and NVS partitions are cleared, next to the flash, this will make sure there is no issue there either) and let me know if you are running into the same issue!
Now the latest stable version 1.20.2.r0 should also work for you, so let me know if you get any issues there. 1.20.3.b0 is a development beta release and not quite stable yet.
Also, I believe the I2C pins on the GPy are P10 and P11, but you can also change that, so Im not too sure..
Best,
Gijs
-
Let me respond to my statement, I2C works on v1.2 as well but the firmware release GPy-1.20.3.b0.tar.gz that we tried seems to have issues. I2C sensors could not be read.
Our fix to be able to read the I2C sensors has been to via CLI downgrade devices from GPy-1.20.3.b0.tar.gz to GPy-1.18.3.tar.gz. Now I hope the I2C error is addressed in a future release.
