@robert-hh Ok thanks, I see the R13 can get lower than 70µA average like 35µA, it may also be related to the measure settings due to the very short 0.3mA spikes in deepsleep

Hi @rcolistete Finally after a few erase_all, reflash, now it s working, I use nvram to store wifi ssid and key set by a web page. It was working fine on wipy but with lopy4 I had a lot of issue. Thanks for reply MS

Dear @cblims, @leifarne and @aarpi3, if you feel lucky, you might want to try one of our custom builds just released at [1,2,3]. More background about this is available through [4]. Please be aware that you will have to erase your device completely before flashing in order to keep things straight. You will find respective references to this on the forum. Hint: Use pycom-fwtool-cli --port /dev/ttyUSB0 erase_all, see also [5]. With kind regards, Andreas. [1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/WiPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [2] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/GPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [3] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/LoPy4-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [4] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480 [5] https://community.hiveeyes.org/t/installing-the-recent-pycom-firmware-1-20-1-r1-requires-erasing-the-flash-memory-completely/2688

@noviniumJeef : I am not sure if the modem firmware update problem that you have was caused by this, but it has been officially acknowledged by Pycom that some devices come with the modem File system in Read-Only state due to a bug in the modem firmware, and in this case, you will get the message Received ERROR from AT+SMSWBOOT=3,1! Aborting! when trying to upgrade the modem firmware, regardless of the method. If this is your case, you should contact Pycom to have the board replaced for you. ( Reference: GitHub - Fail to upgrade GPy LTE Modem #289 )

This is still an issue in the latest frimware! Light sleep mode ( machine.sleep() ) is affected too as bluetooth does not initialise after waking up. Tested with: Pycom MicroPython 1.20.1.r1 [v1.11-3138a13] on 2019-10-08; LoPy4 with ESP32 Pybytes Version: 1.1.3

@seb Thanks! Someone should fix this in doc. I'm running the latest stable firmware on wipy3, SPI device is hooked to default pins (as in pinout diagram) and it wasn't working until I've explicitly passed them in pins during SPI initialization. Most of the day yesterday I was struggling to make it work.

@robert-hh Hi Robert, I've deleted my custom code from the device (using ampy) and I'm now able to connect to it again. Checking what was causing it to hang.

I came across this "bytesdfu-util: Error sending completion packet" error today when attempting to upgrade a Pycom Expansionboard 3.1 connected to an Ubuntu 18.04 LTS. Running ls -la /dev showed that the serialport had restricted access, so a quick fix was: sudoedit /etc/udev/rules.d/50-myusb.rules and insert the following: KERNEL=="ttyUSB[0-9]*",MODE="0666" KERNEL=="ttyACM[0-9]*",MODE="0666" then sudo reboot After rebooting the firmware upgrade worked great (holding the s1 button when connecting the USB-cable; releasing s1 after one second; then running dfu-util within a few seconds). sudo su - dfu-util -D /home/user/Download/expansion31_0.0.11.dfu

@MJ1 Try this updater: https://forum.pycom.io/topic/3454/new-development-firmware-updater-1-15-2-b1 All firmware images are available through: https://forum.pycom.io/topic/2777/downgrading-firmware-advanced-users

I actually gave up on the FiPy for not getting this sorted out. The problem is not in the use of a GPIO to wake the board. The problem is in entering or exiting the deepsleep mode. Now reading some more in the forum I found one reference to sometinh that might be related to the issue that I experienced: @crumble said in Deep Sleep Not Waking Up: @jcaron said in Deep Sleep Not Waking Up: Also, remember that machine.deepsleep never returns. Depends :) If it behaves like the pytrack, it may never go to sleep and never increase the program counter. I assume a catched i2c issue in combination with the pytrack. If the OP has a USB volt meter, he can simply verify this. If it still draws a lot of power, it does not sleep and can therefore never wake up. The software watchdog is able to get it out of this state. On my system it is not easy to reproduce. It may need a few hundred deepsleeps before this error occurs.

@Lucas_Vieira Yes, just change the last line of the method values() to: return t, p, h I never had sent values directly to cayenne, only through TTN. Which cayenne LPP module are you using? Edit: In my tests, the value for humidity was the one with the largest error, but still not 0. Are you sure that you have a BME280 device and not an BMP280? If you look at the package, there are two lines of letters BME280: xxx Ux BMP280: xxx Kx The difference is U vs. K

@Ralph I just tried closing all the files/folders I had open and uploading and it worked! About to try uploading the code I was originally trying to upload. Thank you for the help!!

@robert-hh That's where I thought I got my version. Anyway, thank you. That small difference in version made it work.

@rskoniec thank you so much! I will try that out. That's a good thread. As far as the firmware, I need to double check, but I believe for both I'm using the most updated stable release version.

@robertsehlstedt You're welcome! :o)

@johand Sorry for the delay. I just got back around to this today, and had a win with your commands :). Thanks for your help!!

@iwahdan, the external I2C device now works on I2C bus 2 when using an extended timeout period. Thanks for solving the problem. Dave.