Kickstarter Oak will not first update

[PeterF]

Same here. I narrowed it down to a smaller chunk of memory

Code: [Select]

esptool --baud 115200 --port COM3 read_flash 0x100B00 0x000100 flash_wifi_config.bin
and could also see my WiFi SSID and passwd in the clear. So there is something really odd going on if your SSID is making it intact, but not your password. Any 'odd' characters or symbols in it?

Thanks for pointing out the wifi config memory blocks exeng... that will be very handy as it is an easy way to get my Oaks to forget the AP so I don't need to 'de-particle-ise' them when trying to get them to work with the particle server (and they don't want to play)... once I make a small enough blanking binary to wipe out *just* that bit!!!

Edit: I also get the same error for 0x3FF000... but this is on a Oak that had no WiFi issues, so I don't think it is a sign of memory failure in my case. I may be completely misreading this, or taking it out of context, but I see mention of "0x3ff00000 = peripheral registers base", so it probably isn't program memory space??  

Code: [Select]

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

A fatal error occurred: Failed to enter Flash download mode (result "0x1, 0x6")

[exeng]

I could be wrong but I've seen WiFi credentials in other sectors, specifically the 0x3FC000, 0x3FD000, and 0x3FE000 (I think). I'd have to dump these sectors to verify. I say this because I remember seeing them and posting about the WiFi credentials being in the clear once. I don't pretend to understand the Oak memory map but I know I've seen them elsewhere.

BTW: My backup image has these sectors erased which is further evidence that I capture the sectors when the Oak was first brought to 3 blinks.

[Bobzilla]

Ah, the second link works fine. I'll check it out.

Yeah, the password is not there, just ghost data from something else. I noticed that when I switched from a longer named SSID, ending '321', to a shorter one by two characters ending with 'E', that the 00 byte comes right at the end of that new SSID but the last character and previous 00 byte of the first SSID with the rest of the previous ghost data are still there, represented below.

Code: [Select]

Starting at 0B1D ending at 0B35 ('_' replacing private info and '.' representing 0 byte locations.)
____________321.vant 1234
____________E.1.vant 1234

My SSID passphrases never show up in this block of memory. If it should follow right after the SSID then yes, I'd agree. Something isn't allowing the passphrases to be written there. That seems like there is a possible code error based on some hardware difference in this chip not found in the other four or if it is copied to this area from another malfunctioning area. Given that the software has all been the same, it seems there is a hardware issue somewhere. Perhaps there is an unexpected condition  happening with this unit that isn't accounted for in the software?

Good troubleshooting method there Peter.
However one of the datasheets says:

• User Param: Users can define the address. In IOT_Demo, the four sectors starting from
  0x3C000 are defined as the user parameter area. Users can define any available
  address for this area.

According to that the 0x3FF000 sector should be writable. Maybe something else is going on there.

[exeng]

Bobzilla,

Just for reference the SSID sits at offset 0x000B1D in that sector (0x100000) and the PW at offset 0x000B3E in the same sector.

[PeterF]

I could be wrong but I've seen WiFi credentials in other sectors, specifically the 0x3FC000, 0x3FD000, and 0x3FE000 (I think).

No, not wrong... they are duplicated there also... but I don't know why.

@Bobzilla: Fair enough... There wasn't enough context around the post where I saw the mention of the peripheral registers, so there is a good chance it was talking about runtime memory or something else entirely! :-O

How long is your SSID? Mine was 17 characters, and (making the assumption that is fixed length slots for config data) it looks there is space for a 33 character long SSID (34 if there is no gap at all) before the password field would be overrun??? Baring that, I would suspect that the Oak is somehow faulty... they should all be the same hardware, and since you've done OakRestore, there isn't anything wrong in the software...

[Bobzilla]

Just for snits and giggles I read out to file the 0x3FC000-0x3FFFFF range from my #3 that has been running for months now and the same range from the troubled #4. They are identical! I reread #4 to file a second time wondering if I had accidentally read #3 again.
So, I 'blanked' that area again with the command...

Code: [Select]

python esptool.py --baud 115200 --port COM4 write_flash -fs 32m 0x3FC000 blank.bin 0x3FD000 blank.bin 0x3FE000 blank.bin 0x3FF000 blank.bin with the very same error on sector 4.
Then I read it back out. There was NO change in any of the 4 sectors and certainly not blank! 
Maybe I did something wrong or assumed wrong that it should work that way.
Oh, and in #3 the password is where it should be and another at the end of the program. I'm guessing that perhaps the password doesn't get saved there until after a successful connect? Hmm, there's an idea.
I wrote #3's file back to #4 with this command...

Code: [Select]

esptool --baud 115200 --port COM4 write_flash -fs 32m 0x1000 blank.bin 0x100000 flash_dump_03_0x1.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.binIt is running the program but still not showing on Particle. Oh, well.

[exeng]

Bobzilla, Forgive me for the silly question but you realize that blank is 0xFF throughout. What do you see in these sectors after writing the blank bin file to them?

[Bobzilla]

Yeah, that's what I meant to say. After writing the blank file to those sectors they were not blank (all FF like the file). Those four sectors were surprisingly identical to my working #3 Oak.

That left me with two questions in my mind.

• Is the command to write the blanks actually effective or did I do something wrong?
• If non connecting #4 sectors are identical to working #3 is that area just a red herring?

Though I'd like it to be fully functional, the hunt for a nasty bug is very enticing. I wish this Arduino IDE had debug/stepping capability. The problem with inline serial debugging is you have to know where to put them. When dealing with C libraries they're all over the place. If anyone can point me in the right direction (file) it would cut down on my time.

[PeterF]

Against my Oak, running the first of the two scripts below (on Windows) resulted in a result of two entries in 0x003FC000 related to my wifi config, and two entries in 0x003FD000. 0x003FC000 was blank for me and there were a few bytes of data at the start of 0x003F000.

Running the second erased those sectors (all 4096 bytes of them) - when re-running the second script there was nothing in all four sector dump files.

And yes, I know... I could have simply dumped all four sectors into one file with one read (i.e. esptool.exe --baud 115200 --port COM%COMPort% read_flash 0x003fc000 0x004000 flash_endSectors_0x003FC-0x003FF.bin) ... but I wanted to make it as comparable to the 'erase' as possible.    

Edit: btw... this was WITHOUT re-configuring the Oak inbetween... I simply read it, wiped it, and read it again, with the appropriate power cycles and P2 to GND as needed.

Both scripts use esptool.exe and wipe script needs blank.bin

OakReadEndSectors.cmd

Code: [Select]

@ECHO OFF
SET ESPTOOL=esptool.exe

ECHO Oak Read End Sectors
ECHO ====================
ECHO.
ECHO Available Serial Ports appear to be:
for /f "tokens=4" %%A in ('mode^|findstr "COM[0-9]:"') do echo %%A

ECHO.
set /p COMPort="Which COM port do you want to use (e.g. 3)? "

CHOICE /M "Run esptool on COM%COMPort%"
IF ERRORLEVEL 2 goto end
IF ERRORLEVEL 1 goto run_esptool
goto end

:run_esptool
%ESPTOOL% --baud 115200 --port COM%COMPort% read_flash 0x003fc000 0x001000 flash_endSectors_0x003FC.bin
echo Reconnect Oak
pause
%ESPTOOL% --baud 115200 --port COM%COMPort% read_flash 0x003fd000 0x001000 flash_endSectors_0x003FD.bin
echo Reconnect Oak
pause
%ESPTOOL% --baud 115200 --port COM%COMPort% read_flash 0x003fe000 0x001000 flash_endSectors_0x003FE.bin
echo Reconnect Oak
pause
%ESPTOOL% --baud 115200 --port COM%COMPort% read_flash 0x003ff000 0x001000 flash_endSectors_0x003FF.bin

:end
pause


OakWipeEndSectors.cmd

Code: [Select]

@ECHO OFF
SET ESPTOOL=esptool.exe

ECHO Oak Wipe End Sectors
ECHO ====================
ECHO.
ECHO Available Serial Ports appear to be:
for /f "tokens=4" %%A in ('mode^|findstr "COM[0-9]:"') do echo %%A

ECHO.
set /p COMPort="Which COM port do you want to use (e.g. 3)? "

CHOICE /M "Run esptool on COM%COMPort%"
IF ERRORLEVEL 2 goto end
IF ERRORLEVEL 1 goto run_esptool
goto end

:run_esptool
%ESPTOOL% --baud 115200 --port COM%COMPort% write_flash -fs 32m 0x3FC000 blank.bin 0x3FD000 blank.bin 0x3FE000 blank.bin 0x3FF000 blank.bin

:end
pause