Trying to use my Oak's [Finally]

[PeterF]

Sorry, yes, PortableApps are generally windows only, although you can run a lot of their stuff on Linux using Wine.

If it's doing the triple blink shown on this page, it looks like the update has actually loaded, and everything should be fine... perhaps just a manual claim needed.

Once it's doing that triple blink, there should not be an issue power cycling the Oak, and seeing if it is now behaving... as sometimes the update process doesn't reboot the Oak properly so a manual power cycle knocks some sense into it.

Using the ESP8266 Arduino core you get the WiFi access, you can have OTA programming (which is way faster than Particle as it's all local unless you use another option they have which is to pull from a server, meaning the update file could be located anywhere the ESP8266 can access it), and you can also use stuff like ubidots or thingspeak if you want remote dashboards. It's not as pretty as the Particle integration, but it is more reliable in the long term, and gets around a lot of the issues around the current codebase and particle integration. Erik did say he was going to work on an alternative, but that was put on hold due to the BuildOne kickstarter, so it may be several months before we see anything come of that, and if you have a backup of the firmware, you can always revert back to the Oak native firmware if you want to try it again. Make sure you have a copy for each Oak, as they each have unique keys for authenticating with the Particle servers.

[nefarious]

So, I followed all of the links, have an arduino connected to read the flash using esptool.  I am powering the Oak with the arduino and the green power light on the Oak is on, so I did part of it correct.

To find the /dev to connect to I

ls > foo with the USB cable not connected and
ls > bar with the USB cable connected and then

diff foo bar and it showed two device, /dev/ttyACM0 and /dev/serial.

I first tried //dev/ttyACM0 and after many ....._____ got the error message
Failed to connect to Espressif device: Timed out waiting for packet header

I then thought maybe I need to use the /dev/serial so I followed this link and found the following device

/dev/serial/by-id/usb-Arduino__www.arduino.cc__Arduino_Uno_649323438383513002B1-if00

I tried this device and got the same result:

The entire comand I am sending is

sudo esptool.py --port /dev/ttyACM0 --baud 115200 read_flash 0x00000 0x40000 ACORN-0c4cf0

or

sudo esptool.py --port /dev/serial/by-id/usb-Arduino__www.arduino.cc__Arduino_Uno_6493223438383513002b1-if00 --baud 115200 read_flash 0x00000 0x40000 ACORN-0c4cf0

I tried a slower baud rate with the same result.

When I plug the arduino in the USB I do the following in case the port is just having bad permissions:
sudo usermod -a -G dialout <me>
sudo chmod a+rw .dev/ttyACM0

I don't think this is the problem, but I just had to be sure.

Are there any other diagnostics that I can perform to know what might be wrong.

My connections to the oak are as follows: O -> Oak, A -> Arduino

O:G -> A:G
O:VIN -> A:3.3V
O:RESET -> O:G
O:TX ->  A:TX
O:RX -> Middle of Voltage divider

the voltage divider is 1K x 2.25K

when I run the command the RX and TX led's on the arduino light up.  Is there something I forgot to do?

I will get a real device so I don't have to use the arduino but that means I am dead in the water until next week, Argh!

[PeterF]

Just a tip, you should be look at the dmesg output (dmesg -wH) if you have that running in another terminal window to see what device the arduino connects as.

Anyway, first things first. Yes, you are talking via the Arduino, but I'm pretty sure it's the ttyACM device... to double check, look at what the Arduino IDE calls the port when you have the Arduino plugged in.

Vin on the Oak would go to the Arduino 5v, as VIN is the Oaks voltage regulator. If you use the 3.3v output, you would instead want to be connecting to the Vcc on the Oak, but I would recommend not, as the Arduino regulator may not be beefy enough to cope with the load of the ESP8266 wifi transmitting... Instead just do Oak VIN to Arduino 5v (or just plug the Oak MicroUSB power in, and just keep the ground link).

Tx of one device needs to go to Rx of the other, else they are both transmitting on the same line, and both listening on the same line, and not much else happens.

As far as commands, the below one looked just fine...

Code: [Select]

sudo esptool.py --port /dev/ttyACM0 --baud 115200 read_flash 0x00000 0x40000 ACORN-0c4cf0
... it's pretty much the same as the one I run on Windows (in a script) when backing up an Oak before moving it over to the ESP8266 Core...

Code: [Select]

%ESPTOOL% --baud 115200 --port COM%COMPort% read_flash 0x000000 0x400000 oak_backup.img

(ESPTOOL=esptool.exe and COMPort=3)

[nefarious]

I always connect Rx to Tx and Tx to Rx but I was following directions as below.  I will make the changes as you suggest.  When it works I will attempt to notify the person who produced the instructions to get them correct.

Procedure for Connecting Oak to Arduino with Voltage Divider
Jumper the Arduino RESET pin to ground.
Connect the Arduino ground line to one row in the breadboard.
Connect the Oak ground line to the Arduino ground line via the breadboard.
Insert the larger resistor into the breadboard, connecting one lead to ground and inserting the other lead into an unused row.
Insert the smaller resistor into the breadboard in series with the larger resistor
Connect one lead of the smaller resistor to the open lead from the larger resistor.
This connection point will be called the “junction”.
Insert the other lead into an open row in the breadboard.
Connect the Arduino “RX” pin to the smaller resistor, on the side that is not connected to the junction.
Connect the Oak Rx pin to the junction.
Connect the Oak TX pin directly to the Arduino Tx pin.
If you are using this procedure to restore the Oak, connect pin 2 of the Oak to ground
If you are going to power the Oak with the Arduino, connect the 3.3V pin on the Arduino to Vin on the Oak. Otherwise, insert a micro USB cable into the Oak, leaving the other end unplugged
Once these connections are complete, both the Arduino and Oak may be powered on


And again, thanks for your guidance.

[PeterF]

Actually, sorry, on second thoughts, that is correct in this instance, as you are cheating, and using the Arduino's USB to Serial converter to talk to the ESP8266. So Rx to Rx and Tx to Tx is correct in this case, as they are the opposite for the USB to serial converter already. I was thinking about the Arduino doing the talking, not the USB to serial chip! :-O

I also forgot to mention, another option is to try direct connection of Rx and Tx instead of via the voltage divider on the Oak Rx line, as what is not clearly documented in most places is that the ESP8266 is actually 5v tolerant on the I/O pins, as it has snapback voltage limiting diodes. This will rule out the voltage divider as an issue.

Before you start panicking about connecting 5v outputs of the Arduino to 3.3v inputs of the Oak, as I just wrote in an amendment to the oak tutorial page, the ESP8266 (and hence the Digistump Oak, as the ESP8266 is the microcontroller the Oak is based on) has 5v tolerant I/O pins. You should NOT put 5v on the VCC connector, as that WILL kill the Oak, but due to confusion resulting from mistranslation of the original Chinese datasheet which has been cleared up in later releases, and also by the CEO of Espressif (shown below), the I/O pins of the ESP8266 have snapback diodes that protect the chip from over-voltage up to 5.8v, and also from reverse voltages.

[nefarious]

I made many changes last night and this morning and I can't get it to work.  I ordered this part:

https://www.amazon.com/gp/product/B071LT4792/ref=od_aui_detailpages00?ie=UTF8&psc=1

and it should delivered sometime today.  It should make everything easier.

All of my connections are:

A:Reset -> A:Gnd
A:5V -> O:Vin
A:Gnd->O:Gnd
A:Rx -> O:Rx
A:Tx -> O:Tx
O:Reset -> O:Gnd

One last question:  I do not have to keep track of which oak core came from which device when and if I burn it back?  The only requirement is that they are unique?

[nefarious]

I got the USB Serial adapter and I still get the same error.

I had my son, who has way better eyes then I do check my solder joints.

I removed the oak from the breadboard and use a vom to test that the wires from the USB serial adapter had good connections.

When I plug the oak in I get the green power light,  It is steady green.

The connections are:

O:Vin -> A:3.3V
O:Gnd -> A:Gnd
O:Rx -> A->Tx
O:Tx -> A->Rx
O:Reset ->A:Gnd

ray@Plank:~/Oak$ sudo esptool.py --port /dev/ttyUSB0 --baud 115200 read_flash 0x000000 0x400000 0B41C2.img
esptool.py v2.2
Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to Espressif device: Timed out waiting for packet header

I tried 5v on adapter to Vin and the result is the same.

I can't imagine what is wrong.

Tomorrow I will solder another oak and try it.  I have used the Arduino serial on 3 of them to see if I could get them started so I will first try one that hasn't been opened.  If that works I will go back and check one that I have messed with.

[nefarious]

Soldered up a new board.

First connected power and ground

A:3.3 -> O:VCC
A:Gnd -> 0:Gnd
O:Gnd -> O:Reset

Powered up the Adapter and got the green light. 

In order to get past this first stage does the First setup over particle have to happen?  If so I have just wasted my time.

Anyway, I then connected

A:Rx -> O:Tx
A:Tx -> O:Rx

And got the same result.

I removed the USB cable from the computer and checked the continuity between the solder blob on the 4 Adapter to the 4 solder blobs on the Oak and everything seems fine.

Any Suggestions?

[PeterF]

Ok, firstly, yes, that USB to serial will probably make your life easier, as there won't be any pesky Arduino in the middle.

When you say the Oak's reset pin, do you mean the pin marked RST on the Oak? If so, don't wire that up at all. Next, because that guide  (if it's the one I think it is) was only focused on serial communication, not serial programming, another pin needs to be grounded when the ESP8266 is powered up for serial programming/esptool to work. Have at look at this one on serial firmware programming if you want more detail, but you want VCC, GND, P3/RX, P4/TX connected to your Arduino, and P2 grounded. When you start the Oak/ESP8266 with P2 connected to GND, it boots into a serial programming mode, and will just sit there waiting for esptool to connect.

No, to do either the initial power on, or to do serial programming, first setup on particle does not need to happen. And no, it should not matter which Oak you restore the firmware on to AFAIK, as the unique Particle setup should be tied to the firmware (otherwise, it's tied to the device, which would technically mean only one copy would be needed, but I don't know that part of the Oak firmware that well, so can't say for certain, so one backup for each Oak it is for me).

Hopefully that gets something happening for you now!

[nefarious]

Thank you, somewhere in this process I got the idea that P2 to Gnd was the same as Reset to Gnd, same pin other side of the board.  Reading the flash seems to be working.  Again, thanks for your time.

[nefarious]

I'm getting closer:

There is official Arduino documentation on how to use the oak with the esp82266 here https://arduino-esp8266.readthedocs.io/en/2.4.0/boards.html#digistump-oak   This isn't real news, but it is useful.

I setup like this and try to upload the simplest script with blank setup(){} and loop(){}

error: unknown board: {upload.resetmethod}
known boards are: none ck wifio nodemcu
the selected serial port known boards are: none ck wifio nodemcu

If I google for this on this page https://github.com/esp8266/Arduino/issues/983 i find

 "... it means that esptool 0.4.5 is still
present somewhere. It could be in hardware/esp8266com/esp8266/tools or in
some stray boards manager package copy you might have on your computer."

The only esptool instance I could find was in

~/.arduino15/packages/esp8266/tools/esptool/0.4.12/esptool 
this seems like it is using esptool 0.4.1122 and not 0.4.5

in ~/.arduino15/packages/digistump there is another packages directory with another tools directory with the esptool.py stuff  but no reference to esptool

Somewhere there seems to be a mismatch of technologies, I am trying to sort it all out.  I sent Brendan Halliday a message to see if maybe he knew but his response was

"The version of esp8266 arduino support has moved on in the last few months and so I haven't really tried it with anything except the version that was around at the time (2.3.0). I'll take a look if I have some time but unfortunately this is unlikely."

I am continuing to look.  If anyone has done this before and knows how to do this I would appreciate some pointer.

Also, it seems like every time arduino changes, this will have to be redone.  If this is going to be useful in the long term digistump will need to create and maintain an official variant. 

[PeterF]

I'll have a look in the next day or two. v2.4.0 is basically brand new... only a week or so old, and Digistump Oak support is new, so I don't know if there are any glitches there. I used to program mine as generic ESP8266s, 4M/1M SPIFFS and they were fine. You may want to experiment with the serial baud rate - bring it down to 115200 instead of the default 921600... it could be bugging out.

[PeterF]

Ok, had a minute to try out programming an Oak with v2.4.0 of the ESP8266 core. When you do get it working, one problem you will find is that they haven't done a variant file so the ESP8266 GPIO numbering and the Oak GPIO numbering matches, so you'll need the Oak to ESP GPIO table that's on the wiki... hopefully that can be added in a future update while it's still early days.

Using the default configuration (ESP8266 boards -> DigiStump Oak, 4M/3M SPIFFS or 4M/1M SPIFFS, 80Mhz, 921600)  I was able to load a blink sketch that flashed the onboard LED (referenced as pin 5). I was also able to re-flash the Oak with Oak firmware via the "Oak by Digistump -> Pin 1 in Safe Mode, Manual Config Only" board type when "upload using" was set to Serial. So the two versions of esptool used by the two different board suites seem to be behaving themselves. This was on Arduino IDE 1.8.2 on Ubuntu Linux.

If you think a rogue copy of esptool is knocking around, try running the below command to see where any copies or similarly named files are (bit on the end just hides the 'permission denied' errors that would otherwise clutter the results). Ignore the files in the arduino15/staging folder, they are the files downloaded by the Arduino IDE library and board managers.

Code: [Select]

find / -name "esptool*"  2>/dev/null

[nefarious]

I think I have a giant mix of things going on. 

I am using the Board.txt entry from The"How to remove Particle from your Digispark Oak ESP8266" site as well as their variant .  Should I remove it, or should that be correct?

[nefarious]

I was afraid I had a mix of several esp cores so I just started from scratch.  I'm not sure what I should take from the Particle site so for now I just left it all out.  I extracted the arduino archive in a new place, and ran install.  I then only followed the directions on the page https://arduino-esp8266.readthedocs.io/en/2.4.0/installing.html.

I opened a basic sketch and compiled and attempted to upload it.  I was able to get more information from preferences/'show verbose output during upload'

Arduino: 1.8.5 (Linux), Board: "DigiStump Oak, 80 MHz, 4M (1M SPIFFS), v2 Prebuilt (MSS=536), Disabled, None, 115200"

Archiving built core (caching) in: /tmp/arduino_cache_962739/core/core_esp8266_esp8266_oak_CpuFrequency_80,FlashSize_4M1M,LwIPVariant_v2mss536,Debug_Disabled,DebugLevel_None____,UploadSpeed_115200_87c8508b9b5cd798698478194118aa71.a
Sketch uses 246755 bytes (23%) of program storage space. Maximum is 1044464 bytes.
Global variables use 32784 bytes (40%) of dynamic memory, leaving 49136 bytes for local variables. Maximum is 81920 bytes.
/home/ray/.arduino15/packages/esp8266/tools/esptool/0.4.12/esptool -vv -cd {upload.resetmethod} -cb 115200 -cp /dev/ttyUSB0 -ca 0x00000 -cf /tmp/arduino_build_974140/sketch_jan10a.ino.bin
esptool v0.4.12 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
An error occurred while uploading the sketch
   setting board to {upload.resetmethod}
error: unknown board: {upload.resetmethod}
known boards are: none ck wifio nodemcu

You can see in the call to esptool the bad parameter for -cd {upload.resetmethod}

so I look around and find
~.arduino15/packages/esp8266/hardware/esp8266/boards.txt
which has a board definition for oak but does not have an entry for resetmethod.  I add

oak.upload.resetmethod=ck
which is what I think it should be,.

I then try to upload, it doesn't work but is getting closer.

Arduino: 1.8.5 (Linux), Board: "DigiStump Oak, 80 MHz, 4M (1M SPIFFS), v2 Prebuilt (MSS=536), Disabled, None, 115200"

Archiving built core (caching) in: /tmp/arduino_cache_165464/core/core_esp8266_esp8266_oak_CpuFrequency_80,FlashSize_4M1M,LwIPVariant_v2mss536,Debug_Disabled,DebugLevel_None____,UploadSpeed_115200_87c8508b9b5cd798698478194118aa71.a
Sketch uses 246755 bytes (23%) of program storage space. Maximum is 1044464 bytes.
Global variables use 32784 bytes (40%) of dynamic memory, leaving 49136 bytes for local variables. Maximum is 81920 bytes.
/home/ray/.arduino15/packages/esp8266/tools/esptool/0.4.12/esptool -vv -cd ck -cb 115200 -cp /dev/ttyUSB0 -ca 0x00000 -cf /tmp/arduino_build_107116/sketch_jan10a.ino.bin
esptool v0.4.12 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
   setting board to ck
   setting baudrate from 115200 to 115200
   setting port from  to /dev/ttyUSB0
   setting address from 0x00000000 to 0x00000000
   espcomm_upload_file
   espcomm_upload_mem
opening port /dev/ttyUSB0 at 115200
   tcgetattr
   tcsetattr
   serial open
opening bootloader
resetting board
trying to connect
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
trying to connect
An error occurred while uploading the sketch
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
trying to connect
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
resetting board
trying to connect
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
trying to connect
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
trying to connect
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
resetting board
trying to connect
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
trying to connect
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
trying to connect
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed

I will work more on the rest of it tomorrow.  Any ideas would be useful.  Could it be permissions on ttyUSB0?