no safe boot possible

[robert-hh]

@devinv it was 'erase flash'. The promt you see now after Ctrl-C is from an embedded tiny basic interpreter in the boot ROM.

[devinv]

@robert-hh So what do I do now?
I can not upload anything.
And when I press reset it is definitly trying to launch something.
What can I do with the tiny basic interpreter? It doesn't let me do any command?
How can I go back to a normal state where I can upload things are input basic commande?

[robert-hh]

@devinv I suggested to reinstall the firmware using the pycom firmware updater at https://pycom.io/downloads/.
When you run the downloader, you can select "show advanced seeting" first, an the on one of the next pages you have the option to erase the file system too. verify on that page, that the proper device is shown.
If all is OK, that should bring you to an clean device.
Another method of erasing flash completely is using esptool.py from https://github.com/pycom/pycom-micropython-sigfox/tree/master/esp32/tools. The call is:
python3 esptool.py -p <your_com_port> -b 460800 -c esp32 erase_flash
After erasing with esptool.py, you can reload the firmware using the pycom updater.

[devinv]

@robert-hh As I don't see the options you are talking about I'm not sure I'm using the right tool
Following your link I used pycom_firmware_update_1.15.1.exe.zip

There is no advanced section
There is "Include developement releases", which I don't know if I need to tick or not (tryed both, same result)
In the Communiction section I choose the PORT (COM6), the Speed (115200)
I have the option 'erase flash file system' (which I ticked)
Force update Lora region (I have a sipy, so I don't tick that right??)
A 'flash from local file' option
A type (pybytes, stable or development), which one do I have to choose?

It asks for a pybytes activation token (no idea where I'm supposed to get that?). I can skip that part

Then it instal 1.18.1.r7 [pybytes] and it mentions it is Sipy
and it write after a few minutes : Your Sipy was successfully updated
But then, nothing change I have the same
flash read err, 1000 loop in Atom

[robert-hh]

@devinv You should install the stable version. But besides that all is fine. I use verison 1.15.2 of the updater. Links are here: https://forum.pycom.io/topic/3425/new-beta-firmware-updater-1-15-2-b0
But firmware-wise the results are the same.
As next step, try erasing with esptool.py & reflash. That is the crowbar style of reset and brings the device definitely back to the manufacturing state after assembly.

[devinv]

@robert-hh ok, I tryed this

python esptool.py -p COM6 -b 460800 -c esp32 erase_flash
esptool.py v2.0.1

Got this

esptool.py:2124: DeprecationWarning: inspect.getargspec() is deprecated since Python 3.0, use inspect.signature() or inspect.getfullargspec()
operation_args,,,_ = inspect.getargspec(operation_func)

then this for 30 seconds

Connecting.....................................................
(that takes 30 seconds...)

and then

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header

Is there something else which has to be done before?

[robert-hh]

@devinv Oh yes. You have to connect P2 to GND and press reset, to go in boot mode.
esptool.py does not support the PIC boot mode setting, it uses the espressif mode switch, which is sadly not supported by Pycom hardware.
And there is a more recent version of esptool.py here: https://github.com/espressif/esptool/tree/4dab24e1b28632d270adf7305fe0d008d1acee99

[devinv]

@robert-hh Thank you so much. I'm back on track.

[devinv]

@robert-hh Is it possible that all what I did could create problem with my sipy sending messages to Sigfox?
It doesn't work anymore.

This was working before

sigfox = Sigfox(mode=Sigfox.SIGFOX, rcz=Sigfox.RCZ1)
s = socket.socket(socket.AF_SIGFOX, socket.SOCK_RAW)
s.setblocking(True)
s.setsockopt(socket.SOL_SIGFOX, socket.SO_RX, False)
s.send(bytes([0x01, 0x02, 0x03]))

But not anymore.
No messages arrives to my sigfox account!?

[robert-hh]

@devinv Erasing flash erase all data, including any credentials that existed. But these will normally be restored when you do a firmware install through the Pycom updater. And that needs to work, because sometimes devices are in a state where only a full erase help.
But you may also ask Pycom service. Maybe Sigfox requires another configuration step.

[devinv]

@robert-hh Sorted. I just had desengage the sequence number on my sigfox account.

[goldfishalpha]

Just for the record, I had a similar issue with a LoPy on a Pysense board.
I foolishly got it stuck in a while loop. Pulling p12 high as per the official documentation could not get me back into REPL to reflash the file system, i.e

import os
os.mkfs('/flash')

Reinstalling the firmware with the 'Erase flash file system' option checked worked the end.

Additional: This is not the first time that the official documentation has been wrong or incomplete.
Maybe an update of docs is in order?

[robert-hh]

@goldfishalpha Pulling P12 high and then pushing the reset button should activate safe boot, which does not execute boot.py and main.py on boot. That's almost the same as typing Ctrl-F at the REPL prompt.

[Martinnn]

@goldfishalpha Are you sure you have P12? As you have noted, documentation is pretty buggy and pinout description a mess. You might well have the wrong pin.

[goldfishalpha]

@robert-hh
To qoute the docs directly, " After reset, if P12 pin is held high (i.e. connect it to the 3V3 output pin), the heartbeat LED will begin flashing orange slowly. If after 3 seconds the pin is still held high..." suggesting that the pin should be pulled high AFTER reset.
In fact I did get a flashing orange led, using this method.
My problem was that it appeared to reset once I released P12. I released P12 because I did not want to go to the prvious OTA firware and only wanted to disable boot.py and main.py.
@Martinn
I am sure that I have P12 (and not GPIO12 or '12') as I get the flashing led..

I haven't solved it yet. Just documenting for posterity.

[ferfersan6]

@goldfishalpha
Did you solve it? Having the same problem on a Lopy 4.0. Thanks!!

[robert-hh]

@goldfishalpha If there is a time window where micropython is running, you could try to push Ctrl-F in a terminal window. That forces a safe boot. Ctrl-C may work too. This time slot is hard to catch, because typically you cannot connect a terminal when the device is in deepsleep. An indication for start would be an increase in power consumption. So if you have a USB dongle which shows that, if gives the trigger.

[goldfishalpha]

@ferfersan6 Good intentions pave the way to hell and I had every intention to reply to this. I know this is WAY too late to reply this but may useful for any experiencing the same issues.
If I remember correctly, I just held the pin high for as long as possible and went through the drudgery of reinstalling the proper firmware. Nothing sophisticated going on here! :)