@timh Well in embedded programming for example one of the lpc4000 series with a proper debugger you can "walk" through the code and see at any given point in the code what value any given variable has. That's the real thing i'm missing with python: a decent debugger where i can set breakpoints, evaluate and and manipulate RAM variables and cycle through lines of code. this And i believe that wrapping everything in try and catch can make you a lousy/lazy programmer. For myself i only add try and catch if everything works as it should. Than add them to give the option to continue running with less functionality or save some variables and reboot. As for now i'm liking C much more. But there is also an enormous difference in experience. I've been programming all kinds of embedded microcontrollers in C for years, and probably python is never gonna catch up. I have to get more used to coding in python and i will. I guess i'm not so used anymore to make beginner mistakes ;)

getting further on this problem found list of OSErrors ENOENT means No such file or directory there was a typo in the file path at this point i'm getting other errors at line 121 >>> sqnsupgrade.run('/sd/FIPY_GPY_NB1_37781.dup',921600) <<< Welcome to the SQN3330 firmware updater >>> Entering recovery mode Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/flash/lib/sqnsupgrade.py", line 121, in run TypeError: extra keyword arguments given >>> reading the sqnsupgrade.py says that the line does print('Resetting.', end='', flush=True) guessing it is not important that to print something i removed the line running the upgrade again gives me this >>> sqnsupgrade.run('/sd/FIPY_GPY_NB1_37781.dup',921600) <<< Welcome to the SQN3330 firmware updater >>> Entering recovery mode Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/flash/lib/sqnsupgrade.py", line 123, in run File "/flash/lib/sqnsupgrade.py", line 74, in wait_for_modem TypeError: extra keyword arguments given reading the code at that line 74 gives print('.', end='', flush=True) this makes me think that there is something wrong with the call of the print() function so i removed the flush=True from both lines. after running the sqnsupgrade i now get the following >>> sqnsupgrade.run('/sd/FIPY_GPY_NB1_37781.dup',921600) <<< Welcome to the SQN3330 firmware updater >>> Entering recovery mode Resetting.. Starting STP (DO NOT DISCONNECT POWER!!!) STP started Session opened: version 1, max transfer 8192 bytes Code download failed, aborting! >>> this is how far i am at he moment still looking in to this any help is appreciated edit: after some more trying got some more info if i try the update again i get this error >>> sqnsupgrade.run('/sd/FIPY_GPY_NB1_37781.dup',921600) <<< Welcome to the SQN3330 firmware updater >>> Entering recovery mode AT+SMSWBOOT=3,0 response b'' Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/flash/lib/sqnsupgrade.py", line 131, in run OSError: AT+SMSWBOOT=3,0 failed! the modem is not responsive to any AT commands if i send just AT+CGMI i get ERROR i tried to locate the cause of the error of the code download i eddited the sqnsupgrade.py to find out where this error is generated it is in line 155 except: blob.close() print('Code download failed 2, aborting!') abort = True i'm really out of ideas for the moment

@bucknall For SIgfox backend registration I beleive I need to put the ID and and PAC out put from with hexlifiy print("ID ", ubinascii.hexlify(sigfox.id())) print("PAC ", ubinascii.hexlify(sigfox.pac())) in my case is: ID b'004e3d90' PAC b'c957cd18b7848c0' so ID that I typed is '004e3d90' and PAC 'c957cd18b7848c0' The device seems to be registered but on backend device webpage I can not see it online at all. How I do I know when is connected to the (Luxembourg) Sigfox network and will get online? It is done immediately or shall I wait?

I have also been finding some CANbus issues on powerup. I have been finding similar quirks which cause system wide boot up to cause issues because the pycom module does not always work on the bus. Sometimes this also seems to cause faults for other system. I will be adding 10k pull up and pull downs in my design to help mitigate startup and reprogramming issues. What is the weak pull down resistors? I am guessing between 47k and 100k

Thanks. Is there a way to distinguish a WDT reset (fault condition) vs. a intenden reset by machine.reset()? Best regards Jardar

Checking pycom micropython source I see, that you are not useing the esp-idf functions for performing the update .... so no danger of corrupting the ota_0 slot. Still I wonder why you are doing "your one thing" instead of using the esp-idf functions ... (https://github.com/pycom/pycom-micropython-sigfox/blob/83e2f7f59e28d726a5a1d79377a5ec37f9e0065b/esp32/ftp/updater.c)

@gt1 If you press reset with files open and/or file operations happening the internal FAT filesystem will be “dirty” and everything is deleted on the next boot. Pycom is integrating a new filesystem (LittleFS from ARM) for internal partitions which should be more robust. I don’t nave a release date to share yet.

@jmarcelino Hi, I used a WiPy 3.0.

@nalexopo Yep I used that library and the pololu breakout board. I can't really give you an exact explanation as to what was going on because I didn't connect the signals to a logic analyser/oscilloscope but the only way I could get the module to start responding was with a full reboot. The sensor is very complex and the library doesn't fully implement everything, and my guess is it doesn't recover from errors very well requiring the full reboot. It works really reliably if I don't fiddle with the wires and make sure it has a clean boot. Try lowering your baud rate like I did: i2c = I2C(1, pins=('P6', 'P5'), baudrate=5000) v = VL53L0X.VL53L0X(i2c)

@robert-hh Concurrent access was my first idea too. To test it: I erased the flash to standard boot and main. Then I preloaded the SD with data. Re-ran the FTP test and it still had the same crashes. Using the FTP server on the device is for me is the easiest way. Otherwise I would need to create a Timer to upload data at regular intervals. To keep data transfer low I would need keep the intervals long avoiding me to have the flexibility of choosing which data I want to download and when. To be honest, I'm a bit disappointed by the eagerness of pycom to attack this problem. The same with my other crash report.

@seb Does that mean: tx_power=14 lora.stats() print(lora.stats())

@jon said in Multicast receiver Issue: import socket import pycom server_address = ('', 10001) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) #supposedly automatically works out the socket cast type?? sock.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1) sock.bind(server_address) def rxstream(item1, item2): try: print('starting rxstream') #sock.settimeout(5) while stop > 0: print('before') data, address = sock.recvfrom(64) print('recieved %s from %s port %s' % (data, address[0], address[1])) except OSError as err: print('unexpected exception - on rx stream socket %s' % (err)) except: print('hmmm') finally: print('bye ') pycom.rgbled(0x0000ff) time.sleep(1) _thread.start_new_thread(rxstream, (1,2)) It would seem this is not currently supported in micropython: https://github.com/micropython/micropython/issues/2691 But it is supported in the ESP32 IDF so you could do this in C and make a micropython module if you wanted. See: https://github.com/espressif/esp-idf/tree/master/examples/protocols/udp_multicast

@robert-hh Thanks, that did it! I had to do the P12 to 3.3V for the 7-9s to load the factory firmware. I retested a firmware update and it went back to the unresponsive mode. So I then reformatted the /flash area by running: import os os.mkfs('/flash') A firmware update then worked ok. Thanks again.

@buw I'm surprised that made a difference, I have nearly always upgraded Pysense boards with a module on. But whatever works for you!

@seb A) FiPy+PyTrack+LiPo-Battery (Not-Attached-to-USB3.0) 
Vin = 4.09~4.10 V 3V3 = 3.32 V B) PyTrack+USB-Serial-device (Attached-to—USB3.0) same port as A)
 Vin = 4.85 V 3V3 = 0.23 V C) PyTrack+USB-Serial-device (Attached-to—USB3.0) + Hotswap-in-FiPy same port as A) & B)
 Vin = 4.55 V 3V3 = 3.32 V D) PyTrack+FiPy+NO-USB-Serial-device (Attached-to—USB3.0) same port as A) & B) & C) same combo as C) Just unplugged USB from PyTrack, and re-attached it…
 Vin = 1.69~2.51 V 3V3 = 1.15~1.91 V Also, worth nothing is that if my hand slips with the measuring probes, I get it to “boot-up” by accidentally shorting GROUND & 3V3, and I get a USB-Serial-Devices on my computer [ergo like A), B) & C) …] … And then, I get the same Vin & 3V3 as C) Which makes me conclude that you’ve guys have a Firmware issue!!! … and not a “bad usb-cable” or “bad usb-port” … etc etc. For some reason, in the boot-sequence of the PyTrack Firmware, it choose not to boot-up FiPy and enable USB-Serial … And, again, it’s odd that I can short GROUND & 3V3 with my measuring probes, and then it boots up FiPy and enables USB-Serial…

Could you post the complete core dump, I will pass this on to the firmware team to investigate

My lopy4 arrived and i tested with it, too, although i was pretty sure it wouldn't make a difference. It didn't, it does the same thing. I left my lopy running since yesterday noon and from 270 readings, 223 were correct. So that's around 17-18% loss.

@Xykon , it is now the second time you save my day :)) Successfully updated! You can mark this as solved! Just wanted to point that the command tool didn't work this time, but the python did. Anyway, next step try to connect it to my LoRa AP! Thank you for your help. Regards, (I was using a expansion board)