It seems that the FTDI chip I was using started to brown out. I switched to external power with a DC supply and everything is back to normal. I should've tried that first. I didn't even think of it since for the first couple of weeks the FTDI chip had no issues supplying sufficient power. Regardless, thank you very much for your help @robert-hh

As of last week, I cannot reproduce the error anymore... . If I encounter the issue again, I will write here again.

@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.

@jcaron It's powered off of my desktop Windows 10 PC. It's most likely a timing issue in the FW. My guess would be that during the import a read value is getting corrupted. I know there is no syntax error in the code. the same code can run for a week with a deepsleep reboot every 30 seconds.

@jmarcelino Thanks. I was thinking on something like the FT2232H. I would also say it is difficult but it is for an academic research, so I think it is worthy. :) I have just read that page, but today the OpenOCD page with the compatible JTAG adapters seems to have fallen.

@crumble Thanks for the info. I've subsequently acquired the Particle Boron LTE boards which can actually accomplish my live streaming requirement over LTE with MQTT - and they are way lower power usage than Pycom boards, and it only takes 12 seconds to connect to the network, and it's cheaper. Currently looks like I'll be switching to Particle because of the LTE deficiencies with Pycom, unfortunately. The Cortex M4 power consumption situation (down to 17ma/5V WHILE connected to LTE, idle, zero sleep modes active) blows the Pycom ESP-32 out of the water anyways. Yes, ESP32 is at 240Hz and the Particle Boron is 64Hz. But I will never in a million years need beyond even 24Mhz, and Pycom doesn't give me a way to underclock and match the current consumption. Kind of frustrating/suprising that I can accomplish my task by radio-ing to a cell-tower and back with Particle, but with Pycom short-range LoRa, no-can-do.

Hi everyone. I want to tell you that I have already solved the problem. There is a conflict with the line in which I declare a Pin as output and the moment in which it is transmitted: Pin('P5', mode=Pin.OUT, value=1) What I did was change the pin to P13, this ended the problem and I was able to transmit without any inconvenience and see the data in the Sigfox Backend.: Pin('P13', mode=Pin.OUT, value=1) [image: 1504880079593-upload-1af3b981-1883-46c5-afa3-16dfe2bcb8ef.png]

I looks like a re-flashing of the firmware fixed the issue.

@Lokefar said in Crash on boot: The device is powered by a 3.3V power supply. OK but make sure the the supply can deliver 500mA @ 3.3V. While the board doesn't use this much in normal use, the boot up is particularly demanding and the voltage can dip below what's necessary - for example during WiFi calibration. Most boot crashes are due to inadequate supply.

@tobru From memory I think it was a 10k resister - check the spec sheet for the HC-SR04. I probably just attached it straight onto the expansion board, maybe via a breadboard - I can't remember sorry.

@livius That is funny, because I had this work for 2 months before having issues. Now they seem sporadic. I am worried a sensitivity is now showing itself. But we will see after more testing. thanks

@ssmith That's right. I recall that post. That is definitely an intentional behavior and looks like a Python bug. I have code for esp8266, which intensively modifies global variables, and that runs stable. I had once ISRs, which modified global variables and after a while flagged, that it could not find that variable any more. As far as I recall, that was viper code on esp8266. So there might be similar strange conditions happen here.

The freeze with gc.collect seems to be a bug in the firmware. @daniel is already working on it : https://forum.pycom.io/post/4219

@Shaun - my experience is very similar to yours, I have compromised and changed my code to avoid anything that I know or suspect will cause a problem, but without certain fundamental and reliable building blocks it is impossible to continue. While I applaud their innovation and attempts at pushing the envelope, I wish that communication was better managed, for example I know nothing of this memory issue until you just mentioned it ! I face continued system reboots (Guru mediation unhandled exceptions) , socket disconnections (and never reconnect) and no matter how I streamline my code, I just can't prevent them, as you say there's only so much you can do. I am guessing that their test environment does not include real world examples, but simplistic things like creating a thread that prints 'Hello World' while the main thread does nothing at all. I have also spent soo much unnecessary time trying to convert libraries from esp8266 to esp32 instead of spending time on developing my apps, I would have expected pycom to create a comprehensive 'official' library of various sensor drivers and utilities and use this library to test against when rolling out any new releases.