Oak Bricked?

[wayfarer]

I've managed to mess up my Oak pretty severely. I had a program that connected to wifi (not my work, an open source project) and I somehow set it to use an access point that didn't exist. I thought that I could just start the oak in safe mode (P1->GND) and go back through the WiFi setup routine. I can see the Acorn access point, but the config utility just doesn't work. I've tried the local server to, and different wireless enabled devices. I've tried OakRestore as well, with a bus pirate and a serial breakout board. I always tried TX>RX, RX>TX, GND>GND. Boot up with P2>GND (and hold it there, I assumed). The serial breakout board RX and TX lights flashed when I ran esptool command, copy-pasted from GitHub with my COM port added

Code: [Select]

esptool --baud 115200 --port COM6 write_flash -fs 32m 0x1000 blank.bin 0x2000 oaksetup_restore.bin 0x0081000 oakupdate_restore.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
All I get is. "A fatal error occurred: Failed to connect to ESP8266". I did once get as far as "Erasing flash" by lowering the baud rate. However, it just exited with "A fatal error occurred: Invalid head of packet" soon after. I'm using mini grabbers , but I don't think they would hurt the signal too severely... we're talking kbps here.

I'm at wits end. I can see the access point, and the LED is giving me the 3 blink pattern. But I can't seem to get the oak to respond in any way. I did remove one of the headers with my reflow station. Maybe I killed it. At this point, I just don't know. Open to any suggestions. Thanks ahead of time.

Also worth noting, when I boot up with the serial port in a terminal, I get some gibberish and then "rr" (If P2 is not held to ground. If P2>GND, there si some other text in from of rr).

[exeng]

This may be a case of the blind leading the blind but let's give it a shot, and I'm sure others will pipe in if needed...

3 blink pattern is a good thing. Assuming your Oak is claimed on Particle, you should be able to upload to it assuming it's the currently selected Oak in the OakCLI.

Also worth noting, when I boot up with the serial port in a terminal, I get some gibberish and then "rr" (If P2 is not held to ground. If P2>GND, there si some other text in from of rr).

The ESP8266 will put out info to the serial port at 74880 baud at power on. Seeing this output could be helpful. The Arduino serial console does not support this baud rate as far as I know. I use Realterm when I need to set this baud rate. There are other tools that may also support this rate.

Two places to start:
1. If you have 3 blink and have a Particle account with the Oak active, claimed and selected via the OakCLI you should be able to upload a sketch.
2. If not but see serial output on boot (even if jibberish), set the baud rate to 74880 and let us know what you see.

[PeterF]

I wouldn't go as far as to say blind exeng... maybe compromise on one-eyed? :-P Oh, and btw, the Arduino serial monitor does support 74880 baud... So I actually find it handy to also use 74880 as the serial speed when working with Oaks, as I get both the OakBoot messages (instead of gibberish) and the program output. I use realterm a lot also though when working with linux boxes and serial consoles though

wayfarer, from how you've described this... you can see the Acorn AP put out by the Oak, but for some reason it's not configuring for you? I'll presume you've logged into your particle account on some wifi capable device, then connected to the acorn AP when prompted. Does it get to the next screen where it shows what wifi networks are in range? If so... you are getting a connection to the Oak, as it is what shows the info on that screen (it looks a little like this one). And if it gets that far, does it get stuck on the next screen where it says it is saving the settings to the Oak?

But as exeng said, the triple blink is a good sign... the Oak is in config mode and is waiting for a new program / wifi config change. As far as the flashing, I don't know what is going on there... I wouldn't think the grabbers would be an issue. And the P2 -> GND connection is only needed on power-up... it is a boot-mode config thing. When provisioning my new Oaks, I have just shoved a male to male jumper breadboard jumper wire between GND and P2, connected the power, removed the jumper, and shoved three more jumper wires to GND, TX and RX (and the inverse on the USBtoSerial adapter), held them tight and then flashed them. Haven't had a failure that way yet I usually powered them up first, configured the wifi, let them try and fail to update, and then updated them manually.

[wayfarer]

Thanks for the responses exeng and PeterF. I can't pretend to know why - but I am able to load files now. I'm not aware of having done anything differently. With the entire internet in between, and my own less than steller network, there are just too many variables. My Oak is, however, functioning for my purposes at the moment.

One thing I am still confused about, I still can't access the WiFi configuration menus and my Oak has somehow remembered my (encrypted) WiFi network despite being booted multiple times with P1 and P2 tied to ground. I thought this would clear all settings and require the device to be re-configured. That doesn't seem to be the case. What's more, I'm not sure why I can't get back in to the configuration screen. These aren't issues for me at the moment, but they may eventually become problems if I change APs.

[exeng]

The WiFi credentials are stored in flash once configured. So they are persistent from boot to boot.

Here is the Wiki link for updating WiFi:http://digistump.com/wiki/oak/tutorials/wificonfig

[wayfarer]

We'll, I've found the source of at least some of my frustrations. I have a GPS module that I attached to the RX port of my OAK. It looks like booting up with the stream of data coming in to RX somehow effected the OAK, preventing OTA updates and, in most cases, even loading the sketch. I find it somewhat hard to believe this behavior is intended though. I imagine these boards are booted up with peripherals on the RX port all the time.

[PeterF]

No, that doesn't sound right at all... Can I just confirm this is the Rx on the Oak (P3), and not P4 (Tx on the Oak) - as P4 being held low on bootup is a known issue... but I don't remember seeing any mention of anything on the Rx Pin (P3). I do seem to have a vague recollection of some issue on the ESP8266... but I could be completely wrong on that one. And using Serial.swap() to reassign the TX and RX pins to P6 and P7 (assuming that works on the Oak) will probably be just as bad, as P6 (Oak TX) shouldn't be held high on bootup... although, come to think of it, the GPS shouldn't pull it's Rx line high... worth a try? Otherwise, see if SoftwareSerial will work? Sorry to go all 'avoid the issue' but if it don't work for you... it don't work!

[wayfarer]

Well, my oak seems to be working just fine today. Really scratching my head here but, for now, I think I'll run with it. If I have more trouble, I may reflow the daughterboard in case I damaged it removing my headers. I'm wondering if there is a way to recover if I've corrupted something more fundamental, like if this board can be programmed using JTAG or some similar standard. Otherwise, for this price point, I'll probably just replace if I have more trouble. Thanks guys.

[exeng]

I'm wondering if there is a way to recover if I've corrupted something more fundamental, like if this board can be programmed using JTAG or some similar standard.

Yes you can. I once erased the entire flash and was able to restore the Oak to factory state (That's assuming the ESP8266 is functioning and booting). It's painful but it can be done.

Just be sure to keep a copy of your device ID's for each Oak you have. And get yourself a FTDI serial to USB card if you don't already have one. A near must if you are going to be messing with the Oak, want to factory restore, or do serial updates.

[wayfarer]

Thanks Exeng. I think you're referring to the OakRestore method though, correct? I tried that and didn't have too much luck. Now that my Oak seems to be in working order, I may put a simple sketch together to echo serial input, just to verity the FTDI cable.

[exeng]

Well there is Oak factory restore as documented in Wiki which I have had to do on occasion but no, I was referring to a blanked Oak that I erased all of flash on. I had to put it back together from scratch to get the Oak to function again. I was siting this as an example for you and anyone that thinks, Oh well I'll just give up on a failing Oak and replace it.  Admittedly this is a rare occurrence and I did certainly help it along by erasing all of flash (will never intentionally do that again).

So, again keep a copy of your device ID's and glad to hear you have a FTDI board (3.3v capable). Most of the time a simple factory restore is all that is needed but then you also have to go through the SoftAP configuration again.

[wayfarer]

exeng, is there a writeup on that recovery method? It might be worth bookmarking.

[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

[wayfarer]

Thanks! I will bookmark that just in case I have more trouble. The fact that my Oak wasn't responding to OakRestore previously does worry me. I have saved all the relevant device information.