Author Topic: Blink patterns after factory restore?  (Read 7102 times)

dougal

  • Sr. Member
  • ****
  • Posts: 289
Re: Blink patterns after factory restore?
« Reply #15 on: November 29, 2016, 04:22:09 pm »
So far, no good. But now I'm getting serial output at 115200, which includes this:

Code: [Select]
ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x40100000, len 3632, room 16
tail 0
chksum 0xc0
load 0x3ffe8000, len 352, room 8
tail 8
chksum 0x82
csum 0x82

OakBoot v1 - H,BU,0


dougal

  • Sr. Member
  • ****
  • Posts: 289
Re: Blink patterns after factory restore?
« Reply #16 on: November 29, 2016, 10:06:22 pm »
Success! Finally got my Oak working again!

I think the secret sauce was resetting the ID via serial. That process doesn't give any feedback, so I wasn't sure at first that it had worked. But it finally presented in AP mode and I was able to configure its WiFi and now I see it online in OakTerm. Yay!

PeterF

  • Hero Member
  • *****
  • Posts: 883
Re: Blink patterns after factory restore?
« Reply #17 on: November 30, 2016, 12:47:29 am »
Wooho! Glad kh and exeng got you fixed up... it's alsoways nice to hear there is another Oak (back in) service! :D

Just adding to the serial comms programs... I find termite a handy little app if you want a big window for serial output, but still the facility for input. I liked CoolTerm but had some issues with it crashing before... but it looks like it has been updated since so will have to have another look.

dougal

  • Sr. Member
  • ****
  • Posts: 289
Re: Blink patterns after factory restore?
« Reply #18 on: November 30, 2016, 06:39:21 am »
For future reference, to add custom baud rates to CoolTerm, create a file named 'baudrates.ini' in the same directory as the CoolTerm app (probably /Applications). In that file, just put the baudrates in, one per line. No keywords or section markers needed, just the integer baud rates on lines by themselves.

kh

  • Jr. Member
  • **
  • Posts: 64
  • OakTerm developer
Re: Blink patterns after factory restore?
« Reply #19 on: November 30, 2016, 07:17:02 am »
Success! Finally got my Oak working again!

Great. Out of curiosity, can you look back and pinpoint what operation might have corrupted the device id? Just wondering if it could be this borderline power supply issue, as I've seen a few reports of things going bad with no obvious cause.

dougal

  • Sr. Member
  • ****
  • Posts: 289
Re: Blink patterns after factory restore?
« Reply #20 on: November 30, 2016, 08:20:42 am »
I'm not sure. When my Oak originally crashed, I had added some code that was dealing with string pointers. In the back of my brain, I wondered if I could have messed up a pointer reference somehow, and overwritten memory in my firmware. But I thought that firmware code and user code were in separate address spaces to prevent that? Or are they not? I haven't studied the inner workings of the ESP enough to know, myself.

kh

  • Jr. Member
  • **
  • Posts: 64
  • OakTerm developer
Re: Blink patterns after factory restore?
« Reply #21 on: December 01, 2016, 04:41:33 pm »
But I thought that firmware code and user code were in separate address spaces to prevent that?

Yes, it's not possible to write to the flash simply by assigning a value to a pointer. You have to call dedicated erase/write functions, which are not available from an Arduino sketch. So, you'd have to be very very unlucky to hit just the right buffer overflow that would end up calling the flash write function to erase or overwrite the config sector. Much more likely to be a power fluctuation or other bug that interfered with the config sector write as it happened. The only other possibility I can think of is if you were erasing or programming via the serial port from the command line with esptool, e.g.

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
you could mistakenly overwrite the config sector if you entered the wrong 0xNNNN offsets.