@paloma https://forum.pycom.io/topic/3834/lopy4-will-not-boot-via-battery-power-on-expansion-board/3 https://forum.pycom.io/topic/3436/expansion-board-3-0-battery-power-not-enough-juice/13 https://github.com/pycom/pycom-micropython-sigfox/issues/167 It seems connecting P8 to 3V3 solves the issue (or an issue which is similar to yours, at least). Don't ask me why.

Hi @dpalharini Does the board work when powered with USB? Try pulling P8 high, if you also want to use the SD card, use a 10k pull-up.

@PaulM You might want to look into firmware version 1.19. At the moment it is still in beta, but it adds the option to use LittleFS instead of FAT as the primary filesystem of the internal flash. This prevents data corruption even in the case of power loss during write operations.

@robert-hh Thanks, that is perfect.

@alexpul correct

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

@robert-hh thank you, I reinstalled ATOM and checked the jumpers on the expansion board and the problem solved. thank you

thanks seb, this would work wonders :)

Hello guys, The issue fixed in the IDF is definitely affecting us. We will merge that patch and will be available for our next release this week. Cheers, Daniel

@reidfo I use the boot.py to mount the SD card just once. When I mounted the SD card in the main.py I encountered OSError when re-running my code in the REPL (OSError: the requested operation is not possible) due to the fact that I cannot check the status of the SD card.

Can you please first try another firmware update (we have released 1.10.2.b1). If that doesn't help please try to format the internal flash: import os; os.mkfs('/flash') If that still doesn't help please email support@pycom.io

@livius Thanks a lot. Now both of my LoPy works in AP mode. com port issue is adressed and fix will be released in next firmware @daniel can say when. I hope it is very soon.

daniel said in New firmware release 1.6.12.b1: Fix bug caused by machine.reset(). Used a quick WDT reset instead which actually performs a full reset of the chip.

@bucknall I am able to corrupt the file system pretty easily. Running 1.7.6FW ATM. It seems to be when the program has a file open and an error occurs. What is the file system running on these boards? It doesn't appear to be a journaling file system. It is way too easy to corrupt the file system and have it erase the whole flash. I am developing a BT application that can update any file on the device and really need protection against this type of failure. I'm already doing a double buffer approach with the file writes so I have a good copy of the target file before deleting the original and renaming the file. The issue is resetting the board in the middle of a file write causes any manor of flash corruption. Before someone says "don't do that", I try very hard to design my system to recover from any type of errors. The cardinal rule is that there should be no way to brick a unit doing an update. To that end, I test every kind of failure during updates to make sure the device remains in a operating state.