Kickstarter Oak will not first update

[Bobzilla]

THANK YOU SO MUCH FOR THAT INFO! Really, you pointed me to where I wanted to go but didn't expect to get to so soon.

So, I tried the master reset and the consistent part here is that it will not connect to download the update, just blink blink blink.

Following your instructions (had to install pyserial, for other readers information), close the Arduino IDE Serial Monitor window (apparently gets its own handle to the COM port) and some trouble with my connections, I managed to get the 1.0.5 core written with the #define DEBUG_SETUP. (OH, yeah!)

I found the Arduino IDE Serial Monitor options (none) disappointing so switched to PUTTY to capture the entire serial output.

Adding some more meaningful debug info to the system I found that even though the WiFi is apparently working, after Oak.connect() executes, Oak.waitForConnection() times out and the connection fails. Hence, there is no Particle connect attempt.

I'm now off on a journey of discovery in the bowels of the Oak system to add more debug info in the area where the connection fails. My gut says faulty micro memory somewhere, like a setting isn't taking hold.

A point in the right direction (file) would be great, otherwise, "a huntin I will go".

[PeterF]

Hm... very curious.

I'm afraid that is about the extent of my knowledge of the depths of the Oak... I haven't had any need to fiddle with the wifi stuff so haven't looked into that at all. My prefered text editor (Notepad++) has a handy find in files option gets a good working out - I usually point it at the Oak directory to root through all the files and find interesting bits and work out how the code bolts together.

There was some mention before about a section of memory used to hold the different configuration values... it would be interesting to know if there is any easy or 'safe' way to wipe that so the Oak completely reverts back to "factory defaults". Maybe kh or exeng can shed some light on this if they are following along (as I think they were in the discussion earlier about the config memory block?)

Happy huntin'

[exeng]

If this is a corruption of the final sectors where the WiFi info is stored, the solution is to erase the last several sectors with a command like this according to Erik.

Code: [Select]

python esptool.py --baud 115200 --port YOUR_COM_PORT write_flash -fs 32m 0x3FC000 blank.bin 0x3FD000 blank.bin
0x3FE000 blank.bin 0x3FF000 blank.bin
I once had a misbehaving Oak the was snapped back to working by doing this per Erik's advice. Don't know why it worked but it did. Worth a try.

[Bobzilla]

Wow, that sounds like my gut was right. Here is the output from that command...

Code: [Select]

Connecting...
Erasing flash...
Wrote 4096 bytes at 0x003fc000 in 0.4 seconds (75.2 kbit/s)...
Erasing flash...
Wrote 4096 bytes at 0x003fd000 in 0.4 seconds (74.5 kbit/s)...
Erasing flash...
Wrote 4096 bytes at 0x003fe000 in 0.4 seconds (74.5 kbit/s)...
Erasing flash...

A fatal error occurred: Failed to enter Flash download mode (result "0x1, 0x6")
Houston, I think 0x3FF000 has a problem.

I tried it 3 times, each time checking my connections and a power cycle before the last.

Bad chip?

Is this "ESP8266EX Datasheet - Version 4.3" the right datasheet for the Oak?

[exeng]

Bobzilla,
It's been awhile since I've done this but I recall seeing a similar error when trying to erase the 0x3FF000 sector. It still fixed my problem. In fact I recall mentioning to Erik that I had seen the same error. So I would ignore it for now.

Did this help to fix the problem? Or are you still experiencing the original issue?

[Bobzilla]

Nope, same problem.
I went through all the previous programming steps.
No improvement.

[exeng]

Probably not what you want to hear but I would try factory reset again. Make sure you a good power source.

https://github.com/digistump/OakRestore

[Bobzilla]

No change.

Downloaded OakRestore-master.zip again from your link.

I changed to my Nexus USB charger and ran the gamut.

Changed to local 5V supply into the Vin.

I tried clearing the 0x3FF000 before 0x3FE000.

Nothing different, still won't connect to particle.

[exeng]

I assume you get through the SoftAp config and can still get to three blinks?

I've been there with a couple of my Oaks. One was fixed by extreme measures and the other by what I suggested. It's frustrating I know because there seems to be no if this then do that knowledge.

Has this Oak ever been claimed on Particle?

The extreme measure is documented here (but I wouldn't try that just yet):
https://digistump.com/board/index.php/topic,2381.msg11296.html#msg11296

[Bobzilla]

This one, #4 of 5, has never claimed but does update to system 10 (3 blinks). Obviously I could only do that via serial.

Wow, that is involved. I'm on Windows 7 but have some experience with Linux. (Like to make the switch some day. Need 3D CAD.)

This may take a couple days.

[exeng]

The extreme method was required because I stupidly erased all of flash thinking a factory reset would restore the Oak. I wiped the boot sector among other things. I don't think it's necessary for you because you are getting to the 3 blinks and only seemed to be hung up on connecting to Particle.

You say...

Obviously I could only do that via serial.

Does that mean you are not able to SoftAP update the Oak to configure it via a wireless connection?

[Bobzilla]

Because though the Soft AP comes up and I select a network, it never connects to Particle, so it won't do the OTA update. Have to use serial until this issue is resolved. This is what led to finding that the 0x3FF000 sector is not saving the config.

[exeng]

If you have a way to view hex files (hex editor) you should be able to see your SSID and PW in the bin file at about offset 0x00000B10 in the bin file resulting from this command to read flash.

Code: [Select]

python esptool.py --baud 115200 --port COM3 read_flash 0x100000 0x100000 flash_dump_0x1.bin

[Bobzilla]

I cannot complete step 4 with the Particle CLI https://digistump.com/board/index.php/topic,2381.msg11296.html#msg11296 because I cannot login to get at it. They keep rejecting my particle account login and even the community login and they hide the location for signing up for whatever that login is for as well.

In the flash_dump_0x1.bin file I see my network SSID but the password is not correct or not what I enter.

[exeng]

What you opted to go the extreme route and got through the first 3 steps? And, your blocked at the  SoftAP login to Particle? Or do you mean normal Particle login? Or the link below?

BTW: I can't log in to that link either in kh's message post but can log in to the normal Particle.io. Perhaps when kh posted his summary he linked the wrong login screen? I'll have to look at my notes.

4. The Particle CLI. This is a bit of a pain as it requires several prerequisites - see the installation instructions http://zendesk.particle.io/hc/en-us/articles/203265730-Installing-the-Particle-CLI

RE: the WiFi password not being correct. Could be a clue to why you are having difficultly. Is it even close or garbage? I can see mine clear.

I've been off on other micros so I haven't touched my Oaks for awhile. I have some new ones that I recently ordered. I'll have to try and bring one up. Let me check my notes to see if the Particle link is the one I used to get the Particle CLI install instructions.

EDIT: Should be able to find the Particle CLI instructions for Windows here: https://docs.particle.io/guide/getting-started/connect/photon/#installing-the-particle-cli

Scroll up until you see the Using Windows header. Hopefully this will help.