Failing to factory reset an oak

[gaffe]

One of my two oaks did not show up in my particle list even though connected when visiting /particle. The oak stopped flashing the LED and only have a stable power LED. I blocked it's mac in my AP to force it to AP mode but this failed so I decided to factory restore it.

First tried the oaksetup_restore.bin, with no luck, then the oak_restore_factory.bin, no luck there either, then tried to just force a clean firmware onto it, no luck. Still only the power LED.

Looking at the serial output shows:
ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 3632, room 16
tail 0
chksum 0xdb
load 0x3ffe8000, len 352, room 8
tail 8
chksum 0x99
csum 0x99
csum err
ets_main.c


Any ideas on a next step?

Env: OSX 10.11.4, /dev/cu.SLAB_USBtoUART (CP2102 USB to UART Bridge Controller), SerialTool, Arduino 1.6.5

[defragster]

Try powering it with Pin1 (P1/LED) wired to ground (notes I saw say to remove the wire after 3 seconds) to see if you can get it to run in safe mode.

[gaffe]

Tried safe mode (found it yesterday in the forums).

Today I briefly explored different path. There is an ESP inside, why not program it directly? So I loaded one of my old ESP sketches as if this was a raw ESP and, voila, it behaved as a clean ESP.

So, back to OAK FW. Again flashed firmware_v1 (... ... ...  Leaving...) successfully.

ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 29348, room 16
tail 4
chksum 0x64
load 0xf2f46060, len 825824097, room 4
flash read err, ets_unpack_flash_code
ets_main.c

Tried safe mode again but it consistently starts in (3,7). Flash mode (grounding P2) starts in (1,7) allowing flashing.

Is the "flash read err" in (3,7) relevant?

[defragster]

Yes, these are new good antenna ESP's!  Straight ESP coding from Arduino is only that (No Particle for better and worse) - but is way more efficient and works well with OTA awareness giving 6 second updates over your own WiFi.  I'm not sure how the Particle linkage information is stored and verified - you may have wiped that 'Serial # stamp of approval' rendering it 'not able to boot Particle based firmware'.

@Digistump: There was a note once about being able to take these units to 'Generic ESP' mode and back to 'Particle Approved'. Was that made into a Wiki article?  Does the current 4MB Flash need to be stored first in order to return it to the approved list on Particle?

[PeterF]

@defagster : You probably read that as part of the cautions for the OakRestore process... And all you would do as long as you have the device ID is go through the OakRestore process to restore the Oak to factory defaults and restore the device id, and then go through the whole configure and update firmware process.

This will not restore an Oak that has had its Particle Config overwritten at 0x100000 and 0x201000 - a device where that has occured can be partially restored by this method but then will need its device id set via serial, and you'll need to have recorded it previously. Then connect at 115200 baud and send set\n40\n{"device-id":"123456789012345678901234"}\n where 123456789012345678901234 is replaced by your device-id. You can also send a raw POST to 192.168.0.1/set with the same JSON while connected to the AP of the Oak

If you have already added your Oak to the Particle cloud... then you can grab the device ID from that. Otherwise, I have no idea if they can recover it (or issue a new one) if it wasn't saved before wiping an Oak.

[defragster]

@pfeerick -  thanks that covers what I saw.  Indeed I have already copied off my device ID's three different ways - glad that is all that is needed and not some per device full flash image.

[gaffe]

If that id is what's shown when you read http://192.168.0.1/info, then I have it. I'll wait for more detailed restore guides to appear. I would be surprised should I be the only one to experience this problem : )

Thanks for the help so far!

[gaffe]

Nah, returning to my pair of Oaks after using my clean ESPs I still cannot get one of them to respond correctly. These twins will live the remainder of their days demoted to ESP-12-F modules.

[exeng]

With the help of kh I was able to bring an Oak back to life. ets_main.c could be an indication that boot sector is missing as described here:

"message "ets_main.c" means the bootloader have not found any firmware at 0x0 (and/or? 0x40000 - See more at:http://www.esp8266.com/viewtopic.php?f=9&t=386#sthash.Jp49eBfO.dpuf "

Don't know if this is all that is required as I went through 4 vary tedious steps the first of which was to restore oakboot.bin. Here is the first step per kh's actual (his words) instruction:

1. Write the firmware and update images

Get the Oak bootloader:
Code: [Select]
curl -O https://github.com/digistump/OakBoot/raw/master/oakboot.bin

If you're not familiar with curl, it's just a command line tool for downloading files, but you can also just download these files with your web browser instead. If you want to use curl, it's included with Git for Windows. After installing, open a 'Git Bash Shell' from the Start Menu and then type the command above. All of the commands below can also be run in the Git Bash Shell.

Write the bootloader, config and update firmware:
Code: [Select]
python esptool.py -p YOUR_COM_PORT -b 115200 write_flash -fs 32m 0x0000 oakboot.bin 0x2000 oaksetup_restore.bin 0x81000 oakupdate_restore.bin

The remaining steps involve setting the device ID, server and public keys, then updating the Oak to current firmware. I have notes that I took when doing all this but I am probably not the right person to guide you if it comes to that. Hoping kh will chime in if you need to go the extra miles.

Seeing these problems pop every now and then begs for a wiki describing the Oak memory map, where things are stored and a more advanced restore technique description for the brave and capable. With kh's help I restored and Oak that I erased all flash on.

[PeterF]

@exeng: Funny you would mention that... I was just thinking yesterday that I hadn't gotten around to starting to write that page, and should have some time now to start working on it before uni starts again...

[emardee]

And now is a great time to pick up playing with the Oaks again (eg using them as Oaks rather than generic ESP 12F units), as I hear Erik is about to make an announcement regarding Particle Build IDE progress.... so if I'm correct the Oaks just got a lot more flexible and closer to the original Kickstarter vision! Yay!

Mike

[gaffe]

So, maybe I'll wait for those instructions that restore a blank oak. The current factory restore (both the easy and the "Download firmware 1v" and zap it) will not heal units that are zeroed. Yes, there is the need for the original device id which can be curled in once the unit goes AP, but the current 1-2-3s don't get that far. Any step by step would be appreciated; I still backed the kickstarter for a reason: the oak is a neat idea!

[exeng]

Here is a link to the full instruction for restore that kh provided awhile back...

https://digistump.com/board/index.php/topic,2381.msg11296.html#msg11296

[dougal]

I'm glad I spotted this thread. It might be the ticket to get my mysteriously non-working Oak back into shape.

Then I can get back to work on my garage door controller via HomeKit with homebridge-mqtt.

[theevl]

I have two Oaks with the same phenotype.
When i power them up, the power LED stays on (stable), and the other LED shows no activity.

I have tried to reset them with the Pin 1 to ground for three seconds. It doesn't change the behavior.

I have tried to use a USB-to-Serial CH340G adaptor to follow the new OakSerialUpdate (http://digistump.com/wiki/oak/serialupdate) to restore them, but this has failed also.

I have a Windows10 machine, and when I use the batch file, I get these results.

Enter COM Port of USB-Serial Adapter: COM3
Ensure Oak is attached as shown here and press a key: digistump.com/wiki/oak/serialupdate
Press any key to continue . . .
Updating...
Connecting...

A fatal error occurred: Failed to connect to ESP8266
Done
Press any key to continue . . .


I tried "3" just in case I was supposed to omit the "COM", and I get this:

Enter COM Port of USB-Serial Adapter: 3
Ensure Oak is attached as shown here and press a key: digistump.com/wiki/oak/serialupdate
Press any key to continue . . .
Updating...
Traceback (most recent call last):
  File "<string>", line 715, in <module>
  File "<string>", line 567, in main
  File "<string>", line 66, in __init__
  File "site-packages\serial\serialwin32.py", line 31, in __init__
  File "site-packages\serial\serialutil.py", line 180, in __init__
  File "site-packages\serial\serialwin32.py", line 62, in open
serial.serialutil.SerialException: could not open port '3': WindowsError(2, 'The system cannot find the file specified.')
esptool returned -1
Done
Press any key to continue . .[/size]

Is there anything left to be tried?

thanks
chris