Have I bricked my board?

[markxr]

Hi,

I've tried flashing the latest esp8266 micropython firmware, and it seems thoroughly bricked. I built a new toolchain from git and the latest micropython, but now it won't boot.

Moreover, I get various errors that I think weren't happening before, with "esptool.py". Even the flash_id command appears to timeout often.

Have I worn out the flash with too many flashings?

Or is there something in the latest SDK which just breaks it?

I have managed to successfully "flash" it with the verify command, but it still won't boot and doesn't get very far. Unfortunately I can't read the weird-baud-rate output,

I've got another esp8266 but I think I managed to brick that one with a short-circuit (it seems repairable though, I think i've blown a power supply diode on the dev board not the ESP module itself)

[mianos]

Probably not. I just updated the sdk and project and I got:

esptool.py v1.2-dev
Connecting...
Running Cesanta flasher stub...

A fatal error occurred: Invalid head of packet ('\xe0')
make: *** [deploy] Error 2

I just reflashed it from windows with the LUA so the board is OK.

[markxr]

Ok, this is what happens:

* I have a NodeMCU type development board, similar to this one https://www.gitbook.com/book/smartardui ... it/details

* I have previously flashed with Micropython - lots of times - and I've had software running on it which uses the filesystem. (it has 4Mb flash)

* NOW I have a problem where I can't get it to run at all. I can still flash it and erase the flash etc, using "esptool", but only immediately after power-on. At any other time, including pressing reset, I just get "Timed out waiting for packet header"

I suspect that I may have bricked it. I could compare its behaviour with a 2nd identical board, except I already fried my other board through carelessness.

Any ideas? I've tried the erase flash command in esptool, which apparently works (only immediately after power-on) but it does not restore the board.

Mark

[markxr]

It is looking increasingly like I've managed to wear out the flash at address 0x3c0000. This is far beyond where the Micropython or any other firmware image exists, actually it's close to the end of the flash. I suspect it's the area where the firmware stores the wifi configuration /accesspoint data.

Every time I touch the flash at this address, the device goes into an unuable state. Unfortunately this happens during most normal resets, with any firmware loaded.

The erase_flash command erases the flash up to this "broken" address, but not beyond.

---

My "stumbler" application calls the WLAN.connect() function a lot of times; virtually continuously in fact. If this writes to the flash at the same spot each time, it may be a problem.

I hope it is possible to modify Micropython to connect to accesspoints without triggering a flash write to the same location each time (I think it is possible, the wifi_station_set_config_current function in the SDK appears to do this)

[jms]

In my experience you don't need to explicitly connect unless you're moving your device to another network.

Why did you need to call connect() so often ?

You could in theory replace the flash but what with the cost of the modules...

Jon

[markxr]

I'm opportunistically trying to connect to open access-points to send telemetry back to my server through DNS tunnelling. It sounds strange, but it works.

I'm working on a modified version of connect() which does not save to flash (calling wifi_station_set_config_current in the API)