can't get initial update to work on kickstarter Oaks

[DrasticAction]

Like many others have reported on this forum, I cannot get my original kickstarter Oaks to update. I have tried all the documented methods and troubleshooting guides, but I can never get past the "Saving settings to your device..." message.

I have seen references to modern browsers being a problem but can't find an explanation as to why... and why isn't the Oak documentation and tools updated accordingly?

Now I am trying the direct serial firmware upload, and even that fails. With esptool (on Windows 10) I get:

Code: [Select]

   Connecting...
   A fatal error occurred: Failed to connect to ESP8266I have triple checked the wiring a bunch of times, tried a second Oak, tried reversing the TX/RX, always the same result.
I have sunk about 8 hours into this and gotten nowhere.

For my USB-serial port adapter I am using a USB-BUB from Modern Device https://moderndevice.com/product/usb-bub-ii/.  This device works fine with my 3.3V Arduino clones (JeeNode), uses 3.3V logic and supplies 5V power. Is there any reason it would not work with the Oak instructions at "Loading the first update over serial" http://digistump.com/wiki/oak/tutorials/serialupdate ?
The instructions recommend the CH340G-based adapters, whereas mine uses a FTDI chip, but a serial port is just a serial port, right?

[PeterF]

The documentation and tools haven't been updated because there are currently only a handful of people who are doing stuff with the Oak, and we have either moved over to the official ESP8266 Arduino core instead (to get all the updates and better compatibility that comes with the newer core), have already created whatever projects we intended to make and the Oaks are use doing their thing, or have them still in a draw because we haven't gotten around to doing anything with them yet. Ok, ok, or have given up on them.

Ok, I haven't tried the wifi config of late, nor the first setup as all my oaks are initialised. However, I suspect the issue comes from a bug in the javascript code that the older web browsers ignored or a change in how they are interpreting the instructions, and the code just hasn't been changed to suit.

However, direct serial upload - either for the update, or for a program, is different. It should only come down to a hardware error or a user error for the most part. Yes, a serial port is just a serial port. However, there have been a lot of counterfeit FTDI chips made, which don't work, which is why we recommended the CH340Gs, as they aren't cloned because they're direct from china. Plus they seem to work on all platforms (Linux, Windows, Mac) with minimum hassle compared to others. So, just checking, you know you need to have P2 connected to GND when powering up the Oak, so it goes into serial programming mode? Next, are you powering the Oak via the FTDI board, or via MicroUSB? I'd try powering via the MicroUSB if you haven't done that already - so only have the GND, TX and RX lines connected to the FTDI, and see what happens then.

[ntewinkel]

I'm having the exact same issue, also with the original KickStarter Oak.

And it sounds like I've tried, multiple times, the same things as DrasticAction tried - wires, switch tx/rx, try a different GND connection for P2.
I'm on a Mac, also using a 3.3v usb-Ftdi adapter.
I can use that same adapter to program Pro-Mini Arduinos. (I think the problem with the fake Ftdi chips was that the port didn't show up on the computer at all)

For the Oak, I also tried the GND-to-P1 on power up that is supposed to put it into AP mode, but that didn't work.

In my case the Oak only ever shows the power light on ever, no matter what I do.

When this Oak first arrived, I had a fair bit of trouble getting it going, but then it suddenly went into AP mode and I was able to connect it to Particle and do a few things like control an LED via a webpage. I guess that's been almost 2 years ago now.
Then I put it away because I found a lot of the tools we still under development.

A few days ago I picked it up again (it was stored safely), and I wasn't able to connect to it anymore. I kinda thought something had been updated in the meantime, thus the attempts to reset it and reconnect it.

I'm wondering if maybe there were some quality issues with the original batch? loose connections maybe? I noticed the Acorn board is a little askew on the Oak board.

I kinda hesitate to try the Arduino core directly, as it sounds like it's quite the process to restore it back to the Oak firmware after that.

So what I'm trying to say, short story long, is I would also love to hear a solution to this issue

Thanks,
-Nico

[PeterF]

Hm... since you mentioned you have already had it working before and have had it updated, etc, if powering up with P1 GND'd isn't putting it into safe mode (as long as you haven't disabled it, of course, via the 'No Safe Mode' board option, of course)... then something isn't right with that Oak.

So if you follow the steps at the bottom of this page, does the P1 LED blink as indicated? (you do need to remove the P1-GND link after a few seconds, as that is the LED pin! )

I had one that was really temperamental, and I ended up turning the safe mode completely off as it kept playing up with some code that worked fine on the other Oaks. Other than that, the batch of 10 I have seem fine, but that doesn't mean there aren't lemons!

Since you've already done the Particle activation... from what I can tell, the hard part is done, as it should be possible to recover the token needed from the Particle Console if it were lost. Anyway, if you wanted to try the ESP8266 Arduino core, it is a matter of backing up the Oak's firmware, and then flashing it with an ESP8266 core compiled sketch. If you want to go back to the Oak/Particle stuff, it is just (just!) a matter a restoring that firmware to the Oak.

i.e. On windows, backing up would look like esptool --baud 115200 --port COM5 read_flash 0x000000 0x400000 oak_backup.img
And restoring would most likely be esptool --baud 115200 --port COM5 write_flash 0x000000 oak_backup.img
(educated guess from the commands I've used for manual serial updates and the like in the past for the Oak).

And that would be with the correct serial port set also... and since you're on Mac that would be esptool.py, and probably some /dev/ttyUSB0 type device identifier.

Hoping we'll see a reply from the OP in the not to distant future, as would be good to know how he's going...

[ntewinkel]

Hi Peter,

>So if you follow the steps at the bottom of this page, does the P1 LED blink as indicated?
No it doesn't. It's only the power light that ever lights up, and I did check for AP (Using the WiFi AP list my iMac shows), just in case I have a bad LED.
I tried a few different power supplies too, including iPhone chargers as well as 2 different dedicated Raspberry Pi power supplies. (And yes, count to 3... or 10, and remove the P1-Gnd wire)

>if powering up with P1 GND'd isn't putting it into safe mode (as long as you haven't disabled it, of course, via the 'No Safe Mode' board option, of course)
Hmm, you bring up an interesting point...
I've only ever done the automatic updates, but I wonder if that update may have that safe mode disabled.

But, it could just be a flakey Oak. I looked up my email history from June 11, 2016, when I first tried using the Oak.

I was trying to work with it today but I’m having trouble getting it started.

The tutorial “connecting a new oak” says that I need to perform a factory update - I’m assuming this because mine was a Beta version from being early Kickstarter, plus also the “first power” response only lights up the power LED.

However, following the steps in the Git repository “digistump/OakRestore” gives me a connection error:

“Connecting...
A fatal error occurred: Failed to connect to ESP8266"

Which is exactly the same thing that's happening now.

And then while I was trying this back then on June 11, 2016, I had a lucky break:

I thought I’d connect it to my Mac try to see if I could directly connect to it using the Arduino IDE (it doesn’t, as you already know), but then I noticed there was a lot of blinking activity that wasn’t there before, and magically the Oak appeared as an AP and I was able to complete all the setup steps and get the blink example running on it! Hooray!

It now claims to have firmware version 7...

Then I went on to connect it to Particle.io and created a local webpage to control an LED on the Oak and report status back.

And I guess that's when it went into storage for a year and a half.
And when I pulled it out of storage a few days ago, it wasn't connecting anymore. Sigh. I was hoping to use that slick integration for a quick and easy remote sensor project.

ps, I also noticed on the KickStarter page that the last update Erik left was an apology for the Particle.io integration being broken - I wonder if that's related.

Thanks,
-Nico

[ntewinkel]

ps, I should add a few more clues to the mix...

Last night I thought I'd try my USB-serial adapter on something else, just to make sure that part of the puzzle is ok.

So I updated a Pro-Mini to do some fancy LED flashing. check.

I then pulled out an older model ESP-01 - one of the very early ESP8266 with 8 pins that was sold back then as a WiFi add-on to an Arduino.

It took me a few tries due to different websites showing different wiring connections, but I finally got it updating, and blinking an external LED. check2.

So I compared the wiring with the Oak connections, and see there is one difference - for my ESP-01 I also have CH-PD connected to 3.3v... I think that equates to the EN pin on the OAK?
Could that be making a difference?

My connections for ESP-01 are:
FTDI  -  ESP-01

RX - TX
VCC - CH-PD
(ESP-01 RST not connected)
VCC - +3.3v

GND - GND
(ESP-01 GPIO2 not connected)
GND - GPIO0  (sets programming mode)
TX-RX

After flashing, I added the LED to GPIO2. Apparently it can confuse things if it's on while flashing the update.

ps, I also noticed that Particle.io does not mention the Oak at all. I wonder what that's all about?
https://www.particle.io/products/hardware/compounds

Thanks,
-Nico

[PeterF]

Yeah, I don't know why it's not on the Particle website... Particle never did seem to come as good I would have liked as far as Oak support... it still doesn't even list the Oak in the console dashboard... Used to just say 'Other' before, not it doesn't say anything. At least the particle build IDE is still listing it properly.

As for CH_PD / Enable, on the Oak that should be fine as is, as it has an internal pull-up resistor.

The best place to get info about ESP connections as far as bootloading and running is here...

That still means it's starting to sound more and more like the Oak is broken... Last I tried it, uploading via Particle was... erratic, and slow... hence why I moved to uploading to Oak via serial, or just moving over to the ESP8266 Arduino core. However, this should not affect the Oak going into safe mode, nor should it not be responsive if you attempt serial programming. I'll pull out a Particle-enabled one later tonight and see what happens...

If you want to try backing up the firmware and moving it to the ESP8266 core in the meantime... have a look at Brendan's excellent writeup on the steps...

[PeterF]

Sorry, for my chosen test subject (coincidentally named TryMe)... both dashboard visibility and Particle IDE code upload worked just fine... Fingers crossed this means the Particle issues were resolved, as it was quite bad before.

Next up is to look at is to see if I can work out what this JS error with the config app that people have been reporting is coming from...

[DrasticAction]

However, direct serial upload - either for the update, or for a program, is different. It should only come down to a hardware error or a user error for the most part. Yes, a serial port is just a serial port. However, there have been a lot of counterfeit FTDI chips made, which don't work, which is why we recommended the CH340Gs, as they aren't cloned because they're direct from china. Plus they seem to work on all platforms (Linux, Windows, Mac) with minimum hassle compared to others. So, just checking, you know you need to have P2 connected to GND when powering up the Oak, so it goes into serial programming mode? Next, are you powering the Oak via the FTDI board, or via MicroUSB? I'd try powering via the MicroUSB if you haven't done that already - so only have the GND, TX and RX lines connected to the FTDI, and see what happens then.

Thanks for responding and for your advice.
So I tried it again:
Oak has P2 tied to GND, and the Oak's GND, TX, RX lines connected to the FTDI serial port as prescribed.
Oak power provided via its micro-USB port this time (from a known good phone charger rated at 700mA).
I power up the Oak and the little green LED is on solid... confirming it is in programming mode.
I run esptool with the following command line (on Windows):

Code: [Select]

.\esptool.exe --baud 115200 --port COM3 write_flash -fs 32m 0x1000 blank.bin 0x2000 firmware_v1.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.binI see
Connecting...
and the transmit LED on the serial adapter blinks steadily... for about 6 seconds.
Then I get the same error as before:
A fatal error occurred: Failed to connect to ESP8266
Tried it several times, cycling the Oak power in between.
Tried with another Oak, and another (but same type) of FTDI serial adapter, on a different COM port. Same result.
I can't say if my two USB-serial adapters have counterfeit FTDI chips, but they both work fine with various other ATMEGA 328p boards. I have no idea whether that means they're ok for this.
I have ordered a CH340G serial adapter... will try again when that arrives, probably in the next week or so.

[ntewinkel]

Hi Peter,

Thanks for all the help, I totally appreciate it

>...it's starting to sound more and more like the Oak is broken

That's the impression I'm getting too. Dang, I would have loved to play with that whole platform more.

I plugged it in tonight and checked the WiFi network client list, and it doesn't show up, so I know it's not connecting either.

For now I'm going to go forward with the ESP-01 and see if I can make it do what I need to do. I've already written a couple of simple php scripts to allow getting and setting of values for clientIDs to a JSON file. That's all I need for remote sensing, so that should be all I need to keep that project going.

I've also decided to try some other Oak-like products, including the Adafruit Huzzah and a WeMos D1 mini. It'll be interesting to see how they all compare.

The next step for the Oak, I'm thinking, will be to test continuity from the daughter board to the header pins, to see if all connections are there.
ps, I just checked for shorts between my soldered pins, and noticed P6 to GND is giving very little resistance - could that be the issue? or is that supposed to be connected to GND (via a small resistor) ?

I might try unsoldering the headers as a next step.

Thanks,
-Nico

[PeterF]

P6 looks to have a 10k internal pulldown to GND (or so says my multimeter ), and EN should have a 10k pullup to VCC.

Do you have any way of measuring the power consumption of the Oak? USB Power meter? at 4.88v (low PC USB), it should be drawing around 75ma if it is running properly and the wifi is running. One other final check might be to just power it up, and see if you get any messages on there serial console at 115200 baud or 74880 baud... might give a clue if it's getting stuck in a weird boot mode. Other than that, if you don't have any dodgy solder joints, etc, it's not sounding good.

If you're looking at other boards, the Witty modules might be worth a look... I like it because the USB-serial module can be separated from the ESP8266 module, also making ideal for a custom circuit board where you can easily just pull the module out for upgrades, etc.

Edit: Schematic for the Oak... although there really isn't much there after the Acorn...

[ntewinkel]

Hi Peter,

Ok, 10k is pretty much exactly what I was getting so I think that's probably ok.

The power consumed is less than 10ma, as it's not showing up on my little meter (which says 0.000 A used).

I haven't had a chance to connect to serial again, but that's a really good idea. Hesitating to unplug that mess of wires from the ESP-01 now though haha.

I like the look of that Witty module! Thanks for the suggestion, I've gone ahead and ordered one
And yes, great design with the piggyback headers like that. That would indeed work well for custom builds.

Thanks,
-Nico