@constantinos Just in case this is still a problem. I couldn't upgrade the pysense firmware at all in Windows or Linux using the instructions here until I used 'sudo' in Linux. I've not tried it yet but I imagine running the Windows command prompt in administrator mode may work.

Every update seems to be different. This time, the PyTrack was detected as a COM device. With the same number as before :). But I was not able to connect. To fix it, I had to select show unconnected devices in the device manager, browsed for the usk driver and deleted the unknown and unconnected device.

@jcaron I did not try those modifications as calling lora.power_mode(LoRa.SLEEP) before machine.deepsleep() made transmission reliable. On the other hand it may be possible that without this precaution ESP32 enters deep-sleep before transmission is finished.

@daniel I did try to erase the flash using esptool and then flashed 1.9.2.b2 with updater.py. Unfortunatelly L01 soldered on OEM baseboard is unstable in case WiFi client connects to it. ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff9010,len:12 ho 0 tail 12 room 4 load:0x3fff9020,len:388 load:0x40078000,len:11584 load:0x4009fb00,len:848 entry 0x4009fc9c MicroPython v1.8.6-796-g489fafa0 on 2017-10-15; LoPy with ESP32 Type "help()" for more information. >>> os.uname() (sysname='LoPy', nodename='LoPy', release='1.9.2.b2', version='v1.8.6-796-g489fafa0 on 2017-10-15', machine='LoPy with ESP32', lorawan='1.0.0') >>> import time >>> while True: ... print(time.time()) ... time.sleep(1) ... ... ... 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 Guru Meditation Error of type IllegalInstruction occurred on core 0. Exception was unhandled. Register dump: PC : 0x40151ff4 PS : 0x00060630 A0 : 0x80152198 A1 : 0x3ffb6e10 A2 : 0x3ffb6e60 A3 : 0x00000002 A4 : 0x0000000a A5 : 0x0000000a A6 : 0x00000000 A7 : 0x0000000a A8 : 0x00000000 A9 : 0x00000008 A10 : 0x3ffb6340 A11 : 0x00000000 A12 : 0x00000000 A13 : 0x3ffb6eb4 A14 : 0x0000000a A15 : 0x00000000 SAR : 0x00000019 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff Backtrace: 0x40151ff4:0x3ffb6e10 0x40152195:0x3ffb6e40 0x401523e7:0x3ffb6e60 0x40152b2c:0x3ffb6e90 0x40143335:0x3ffb6eb0 Guru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x40089d09 PS : 0x00060033 A0 : 0x80088b46 A1 : 0x3ffb6a50 A2 : 0x3ffb6aa0 A3 : 0x3ffb6a70 A4 : 0x00000000 A5 : 0x3ffc482c A6 : 0x00000000 A7 : 0x3ffc4848 A8 : 0x00000012 A9 : 0x3ffb6a20 A10 : 0x3ffb6ae8 A11 : 0x3ffb6a70 A12 : 0x3ffc4bb8 A13 : 0x3ffb6e40 A14 : 0x3ffdbca8 A15 : 0x3ffb6e60 SAR : 0x00000014 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000 Backtrace: 0x40089d09:0x3ffb6a50 0x40088b43:0x3ffb6a70 0x4008ae65:0x3ffb6aa0 0x4008b1da:0x3ffb6c70 0x4008aae5:0x3ffb6cb0 0x4008ac60:0x3ffb6d30 0x40081672:0x3ffb6d50 0x40151ff1:0x3ffb6e10 0x40151ff1:0x3ffb6e40 0x401523e7:0x3ffb6e60 0x40152b2c:0x3ffb6e90 0x40143335:0x3ffb6eb0 Guru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x40089d09 PS : 0x00060033 A0 : 0x80088b46 A1 : 0x3ffb6690 A2 : 0x3ffb66e0 A3 : 0x3ffb66b0 A4 : 0x00000000 A5 : 0x3ffc482c A6 : 0x00000000 A7 : 0x3ffc4848 A8 : 0x00000012 A9 : 0x3ffb6660 A10 : 0x3ffb6728 A11 : 0x3ffb66b0 A12 : 0x3ffc4bb8 A13 : 0x3ffb6a70 A14 : 0x3ffb6aa0 A15 : 0x00000020 SAR : 0x00000019 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000 Backtrace: 0x40089d09:0x3ffb6690 0x40088b43:0x3ffb66b0 0x4008ae65:0x3ffb66e0 0x4008b1da:0x3ffb68b0 0x4008aae5:0x3ffb68f0 0x4008ac60:0x3ffb6970 0x40081672:0x3ffb6990 0x40089d06:0x3ffb6a50 0x40089d06:0x3ffb6a70 0x4008ae65:0x3ffb6aa0 0x4008b1da:0x3ffb6c70 0x4008aae5:0x3ffb6cb0 0x4008ac60:0x3ffb6d30 0x40081672:0x3ffb6d50 0x40151ff1:0x3ffb6e10 0x40151ff1:0x3ffb6e40 0x401523e7:0x3ffb6e60 0x40152b2c:0x3ffb6e90 0x40143335:0x3ffb6eb0

Guys, thanks for the valuable input. We will create the "best practices for deepsleep" section in the docs and also improve the behaviour of the deinit() methods. Cheers, Daniel

@robert-hh Thank you, I forgot to limit the connections

@daniel @bucknall Ping! This is the same issue as: https://github.com/pycom/pycom-micropython-sigfox/issues/68

@bastler said in Wify AP mode not Working After firmware update: BTW, the pyupgrade script (toolversion=67634306) I got from debian apt-get Has a bug in lines 177..183: How did you get pyupgrade woth apt-get? You should load it from here: https://pycom.io/downloads/ During update it should be clear which type of device will be loaded. Loading the wrong formware is not expected to work. In the serial terminal REPL prompt, you should be able to tell. Just enter: import uos uos.uname() or push Ctrl-B Edit: if anything else fails, try to start over by erasing the flash, using esptool.py Edit 2: Indeed, lines 177..183 look strange, but they are only used for manual device selection. This looks like a candidate for a bug report here: https://github.com/pycom/pycom-micropython-sigfox

Ok, however, let's imagine the following situation: I boot it up, it's the first boot. It checks the nvs for a certain value, it does not find it. It sets up that value saying that the next boot isn't the first. After the deepsleep, it will know that it isn't the first boot. But, if I reset the board, it will still think that it's not the first boot. How can I get around this ?

Aha, LoPy 1.7.8-b1 micropython 1.8.6-724 loran 1.0.0 Alright I'm going to update the lot. Maybe some hints in the doc like micropython does with the different versions....

@daniel the failure is on the first wake-up. I don't have a multimeter handy, but can do that this evening. I added @jojo suggestion and the board wakes now. I have left it in a sleep wake cycle and will see how long it runs.

The issue was posted on github.

Hi @bucknall, My code does this: uart = UART(1, baudrate=9600) The deepsleep.py library does this: self.uart = UART(1, baudrate=10000, pins=(COMM_PIN, )) I did not expect the deepsleep library to use UART, hence the initial confusion. The docs state there are two UARTs on the LoPy but i did not find out how to differentiate the two yet (I'm still new to micropython). My current workaround is to re-initialise the UART every time it is used. I will revisit this issue when the following blocking issue is solved: https://forum.pycom.io/topic/1685/lopy-with-deep-sleep-shield-hangs-after-x-go_to_sleep-commands

Just released 1.7.9.b3 which solves the ABP issue. Apologies for this bug, we'll investigate why it was not picked up by our automatic tests.

@bmarkus thanks for reporting this. Fixing it now...