Guidance sought for a semi bricked Oak (short version)

[exeng]

If you have been following my recent posts regarding the ongoing saga of 2 Oaks currently under debug, I seemed to have dug myself a hole by erasing flash on the 2nd Oak (that was working but started to misbehave).  I'm posting this short version of the post because the original (more detailed post) is stuck pending approval.

So my plea is for anyone (Erik?, kh? et al?) who can guide me towards the required steps to bring it back to the Oak world. Think of it as a new piece of HW that needs to be provisioned as an Oak. I have my device ID saved but may have lost other critical info... not sure.

This is and can be a great learning exercise (al beit painful).

Can anyone help?

exeng

[exeng]

BTW the Oak will boot to this message: " ets Jan  8 2013,rst cause:2, boot mode:(3,7)                                                               
ets_main.c"
but no further. I can read and write flash but that's it. Again flash was erased by me and not recommended.

[PeterF]

lol... yeah, I certainly wouldn't recommend it either, although if you have your device ID, AFAIK, that is all you need to recover the 'lil bugger.
Rst cause 2 indicates that the reset was caused by the reset pin. Boot mode 3 means it's trying to boot from the flash memory (normal for an Oak).

Oh shivers... I just remembered when writing the below bit that there is also a claim code... I hope that isn't needed!?! You could try anyway while you wait for someone in the know to respond.... Although... since you have already claimed the Oak, maybe that doesn't matter. I can see on my test subject that the claim code is "", so it doesn't seem to be needed anymore.

What does doing an OakRestore do? Once you get the base firmware on you should be able to either use the internal server URLs to set the device-id, or via the serial console. From the internal URLs reference, the "set" parameters will do the trick. I just don't know what the url format is then... maybe  just http://192.168.0.1/set?device-id=DEVICEID

The serial terminal bit is a bit easier to work out (I think?). You should be able to connect to there serial console when the Oak is in it's triple blink flash mode (115200 baud), and send the following commands to it (with the necessary changes of course!) the 40 appears to be a reference to how long the next line is, 40 characters in this case.

Code: [Select]

set
40
{"device-id":"deviceiddeviceiddeviceid"}

You'll get a message that says =DEVICEID= three times and {"r":0} if you get it right, and it looks like you get a  {"r":-1} if you get it wrong. You can check the 192.168.0.1/info page to see if the device ID took, or on the serial console type in /info

[exeng]

Pete,
With some offline guidance from kh I managed to restore the boot master bin file. The next steps were a guess on my part as the config sectors were erased. kh mentioned that other steps would be needed if this were the case. So I "borrowed" config images from another Oak which happened to be the OTA upload failing Oak. Replaced the device id in both config sectors was able to do a factory restore and SoftAP OTA update. First SoftAP update attempt indicated a missing device id and prompted for it (I was pleasantly surprised). So it's basically alive again with the 3 blink pattern reporting the correct device id but the claim process has not been successful yet. The Oak is never auto claimed and I can't manual claim it. Still trying to figure that out.

Probably should have used one of my other Oak's to get the config sectors from and I will if this deadends. I can still do that but for now I will try to get this Oak back to it's working state.

[PeterF]

lol... as long as you've gotten somewhere, except for deeper, alls good. Thanks for the update.

Yes, that is an interesting coincidence... we were thinking that it was on on the particle end, but copying the config stuff to another oak migrated the issue? That doesn't completely rule out Particle, but it makes it seems more like something hinky in the device config stuff... but why?

Anyhoo, progress has been made

[exeng]

With the help of Dr. kh (a well deserved and honorable title that I bestow upon him), I managed to bring my spare OAK from near death (semi bricked as I refer to it).

This all started when a new working Oak started to misbehave and I (stupidly) decided to erase flash as a last resort.  This of course wiped everything except a boot loader. So how did I get into this state...? Can't be sure but I'm guessing it was marginal power during a serial update. Most likely a less than quality USB cable. It went from working to exception (29) to near death.

So here are the take aways:
1. Don't erase flash unless it is the last resort and you know how to recover from near death. It can be done but it is tedious, painful and requires many tools and some expert guidance.
2. Ensure that you a giving your Oak quality power, both supply and cable.
3. You'll learn a lot if you have to do this but it will test your patience.
4. And finally, "Dr." kh is a genius.

This case is closed.

[kh]

1. Don't erase flash unless it is the last resort and you know how to recover from near death. It can be done but it is tedious, painful and requires many tools and some expert guidance.

The recovery instructions are in the other thread, should anyone get into this situation and desperately need them. However, try your best to avoid this. As exeng said, it's tedious and painful.

[PeterF]

I agree exeng... he deserves the honorary title!!

If kh has no objections, I'll copy those instructions onto the wiki later in the week (with acknowledgements naturally!) as the last resort for recovering b0rked firmware oaks. 

[kh]

If kh has no objections, I'll copy those instructions onto the wiki later in the week (with acknowledgements naturally!) as the last resort for recovering b0rked firmware oaks. 

Sure, go for it. As I said, I don't know for sure that all these steps are necessary.