LoneTech - thank you so much for your detailed clarification! I will give it a try and share my findings with the forum. Thanks again!

@abilio This is what caused the problem. The loop never finishes and comes up with Error 28. As I did not know that it meant "no space available" but guessed as much, I deleted the file that had been written. It disappeared from the directory and although the LoPy would allow me to create new files with os.open('filename','w') it would not let me write to the new file as Error 28 was returned. It would seem that deleting a file is not enough and a full os.mkfs('/flash') is needed to get things working again. I was not able to find anything that would let me find how much free space or capacity there was on the flash file system. Is there something I have missed? [image: 1477919501294-lopy_fillmemory-resized.jpg] When program runs, it turns off the heartbeat, turns the led green and should (if all went well) end with the led turning red and the file being closed. With the error, the led never goes red and the file is not closed by the program.

Here is some example code that worked for me working with the expansion board. If this causes an error for you I would try the latest firmware. I am on 9.2.b2. Another trap for young players is that you cannot reference a variable in the global space directly from an interrupt callback so you need to create a class. The second example is how to get that working. Example 1 from machine import Pin import time led = Pin('G16', mode=Pin.OUT) def drip(p): led.toggle() print('pin change', p) button = Pin('G17', mode=Pin.IN, pull=Pin.PULL_UP) button.irq(trigger=Pin.IRQ_RISING, handler=drip) Example 2 from machine import Pin import time class Drips: pass drips = Drips() drips.count = 0 def drip(p): drips.count+=1 button = Pin('G17', mode=Pin.IN, pull=Pin.PULL_UP) button.irq(trigger=Pin.IRQ_RISING, handler=drip)

Thanks for the report. The fix will be available on the next release. Cheers, Daniel

It doesn't seem related to the actual peripheral device, I'm having exactly the same behaviour shown on a soil monitor over UART1 too... Yeah, the ESP8266 only has a single read/write UART as far as I understand but from the ESP32 spec sheet it has multiple full UART channels. It'd be nice if we had a full pin map. edit: not exactly related but it seems that using 'G23' pin also causes disables the rgb led and as I had this uart initialization in main.py it also stopped firmware updates from working too... :-|

@bmarkus said in Is wireless fw update dropped?: Last fw updates require serial connection. Does it mean that wireless fw update feature dropped from now? No, the current updater via serial port is only to fix an issue with the bootloader (the one that shipped with the WiPy2 / LoPy has a bug causing the random parts of the flash to become read-only). Once the bootloader is updated you can go back to updating via Wifi (though PyCom hasn't released a GUI WIFI updater with the latest firmware you can always use the manual method with Filezilla).

Same here! Windows 10

Thanks! This works.

@littlebat Thank you !

@gertjanvanhethof you are working at a lower level than strings. In python 3.0 and later strings and raw bytes were separated to allow better control of string encoding with unicode. In general your "Hello" is a python unicode string and the sockets work on bytes. send and recv work on bytes, not strings. It looks like send did not error out on the data type, So it must be coping with unicode strings some how... so for a quick hack... if b'Hello' in data: print("Got my data!") For a better change, explicitly convert your strings at the appropriate level in your code. Like theses changes. Change your code to the following in the server. s.send('Hello from LoPy!'.encode('utf-8)) Change your receive code s.recv(64).decode('utf-8') My test sessions in the repl. Server: >>> from network import LoRa >>> import socket >>> lora = LoRa(mode=LoRa.LORA) >>> s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) >>> s.set settimeout setblocking >>> s.setblocking(False) >>> s.send(b'hello?') 6 Client >>> from network import LoRa >>> import socket >>> lora = LoRa(mode=LoRa.LORA) >>> s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) >>> s.recv(64) b'hello?'

I found the entry in the topic about changing the speed in updater,py and commenting out a line and now it works. I should have read all the comments. https://forum.pycom.io/topic/88/how-to-solve-the-firmware-update-failures/55

in the latest release it was said it does, however no example or info about it and nothing changed on that. how about have them get ABP/OTAA (thus lora base) working first before stuff like ADR ;)

@jeremy I did; there was a different problem (two of the lopys got corrupted versions in flash, one was readonly), which I've worked around as described in the how to solve the firmware update failures thread. I did once upload without naming it properly which explains the fourth mystery copy.

@daniel said in 0.9.1.b1 is crashing in 15 seconds: Hello bmarkus, Do you have any scripts running on the board? I think your problem could be related to this: https://forum.pycom.io/topic/88/how-to-solve-the-firmware-update-failures Would you be able to run that tool and let us know if that fixes your LoPy? Anyway, we are preparing a new tool that will completely reflash the LoPy (bootloader included), once Espressif fixes the bug in the IDF that is messing with the external flash status register and causing these weird failures. Cheers, Daniel @daniel No, nothing is running, system is clean as it was shipped, only fw update applied. I'm busy now, will wait for the friday update.

Yes, the sticker is upside down on my LoPy as well. As a consequence I did mount it the wrong way first time but it survived. If in doubt, match the pins on your LoPy with the pins on the extension board. PIN layouts for the extension board can be found here: https://github.com/wipy/wipy/blob/master/docs/User_manual_exp_board.pdf