Digistump Forums
The Oak by Digistump => Oak Support => Topic started by: nefarious on January 02, 2018, 11:54:59 am
-
I bought 10 Oak devices at the Kickstarter and finally have a project and time to use one. I am trying to perform the first time setup and it doesn't seem to be working.
First I do not intend to use the Particle Cloud, my intention is to build a wireless device that I will use locally in my house. I hope this isn't a problem.
What I have done so far:
I connect the oak to a USB cable and both lights seem correct. One is blinking and one is steady on.
I have disconnected the Ethernet cable from my computer and connect to the internet wirelessly.
I go to: http://rawgit.com/digistump/OakSoftAP/master/config.html
I try to connect to the ACORN-0b8d4c network and the graphic tells me it is attempting to connect to my oak until the connection closes and I am then offline.
Do I need to reflash the device? What else could be wrong.
-
I have been working with my Kickstarter Oaks for the first time this week, too, and had some trouble getting things working with up-to-date browsers. I tried current versions of Firefox and Chrome and met with a Javascript error during the step of saving the wifi settings to the device. I had to install an older version of Firefox (45.6.0) on my laptop to be able to finally get things to work.
I downloaded the 64bit version for Windows from here: https://ftp.mozilla.org/pub/firefox/releases/45.6.0esr/win64/en-US/
If you need a different platform, just back up a few directories and you should be able to find it.
-
I finally got connected to ACORN-0b8d4c and it asked me for the main wireless connection. I got that working and it said it was updating to the device. I let it run for 6 or 7 minutes the first time and it just keep updating ... There are no indicators on the board that anything is happening. I finally killed it, and started it again, who knows. The second time I just let it run 4 minutes and killed it. I then wondered if it had worked and they failed to tell me?
I tried to run the oak program before I try to log into the IDE and it fails to find a device, it must not have worked.
I am running on ubuntu Linux if that helps any.
I am running on chrome, I will try firefox next. It is unfortunate if the device doesn't run on the latest browser, firefox updates automatically so going backward is a PITA.
-
I tried on Firefox 57.0.3 and the experience was better, but still disconnected. I got the message at the top of the screen
Attempting to connect to your oak...
for a few minutes and it then goes to disconnected.
-
OMG.. same here (getting back to messing with my kickstarter edition OAKs).
I can't believe installing a >1 year old browser got me further along in this process. It's embarrassing.
However, it appears to update for me, but keeps popping back to the AP mode. :/
Clarification: got 2 of the 3 to update, but neither connects to the cloud.
-
I had to manually claim my Oaks through Particle:
http://digistump.com/wiki/oak/tutorials/manual_claim
I skipped steps 2 and 3 since I had at least one of my Oaks say "connected" and at least one say "not connected" and the process seemed to work for all three of them.
-
Success! Manual association worked!
Got one talking.. will try #2 then see about manually reflashing #3.
-
I think the question for me is: Can I build something useful with them and expect support in a couple of years. I want to build my electric brewery with them and the project needs 8 of the 10 I have. I don't want to have to rebuild it in a couple of years when there is no support for them.
Why I say this: I have had them in their original box for over a year and still, the method of choice for setting them up doesn't work. I plan to publish the build for my brewery and others will want to do the same. I'll give all of the hardware design and software to anyone who wants to copy. Should I use these devices?
-
The easiest way to revert to an earlier browser (edit: on Windows!) would be to grab one of the PortableApps versions... i.e. Mozilla Firefox Portable 45 ESR (https://sourceforge.net/projects/portableapps/files/Mozilla%20Firefox%2C%20Portable%20Ed./Mozilla%20Firefox%20ESR%2C%20Portable%20Edition%2045.5.1/) ... it'll be totally independent of your browser of choice (you just need to close your installed version of Firefox before running the portable version. And yes, it is embarrassing that the browser makers have broken HTML and JavaScript code that was working perfectly will prior to them fiddling around again with their browsers again!
As far as support, if you have no intentions of using Particle, then for longevities sake, switch to the ESP8266 Arduino core (https://github.com/esp8266/Arduino). You'll get more compatibility with existing code, and all the newer features that have been brought to the ESP8266 Arduino core since the Oak split from the main project (to add Particle OTA support, as OTA support didn't exist at the time Erik started on the Oak). Brendan (nog3) did an excellent write-up (http://nog3.net/2017/06/05/removing-particle-from-oak/) on how to change over to the ESP8266 Arduino core. I would recommend backing up the Oak as he suggested, as that will save your Particle keys if you do later change your mind and want to go back to using the Particle cloud for something. There is an update in the pipeline that will remove the requirement for the 'boards.txt' edit , but it isn't in the stable release channel yet. Edit: 2.4.0 was released two days ago, which includes the Digistump Oak boards.txt definition.
As a bonus, you then have full control over if and when the ESP8266 connects to the WiFi (and what network) so you can more easily write power efficient code, and you can also do OTA via the ArduinoOTA library included with the ESP8266 core. It is a local OTA solution, so no external server required!
-
I looked at PortableApps versions... i.e. Mozilla Firefox Portable 45 ESR ... and it seems to be a windows executable. So I can't use that.
I am going to try the Manual approach as posted by theJim. If that will get me going I can see how to make the Oaks work for my project.
-
The first step of the manual claim process is:
Connect to your Oak's wifi network with a computer/smartphone/tablet/etc (which is available only when the Oak is in config mode/new) - with the SSID ACORN-XXXXX. If you can't see your Oak due to it now being connected to your wireless network, follow the instructions on the troubleshooting page to put it into safe mode.
So I have a network ACORN-0b8d4c and when I try to connect to it it connects for a small period and then goes disconnected. So I went to the trouble shooting page and it tells me to go to claim, i tried most of the things on the trouble shooting page to no avail.
I tried to put the device in safe mode and it would only blink at the single blink rate. Since i have 10 of them, I decided to see if it is the oak and got a new one. I plugged it in and it took way long, but eventually started blinking,. So far so good.
I found its SSID as ACORN-0c4cf0
I try to login to my particle account and nothing.
I try to put this device in Safe Mode, same result. I assume Safe Mode is still put a jumper between P1 and Gnd and then apply power. Remove jumper after 2 or 3 seconds. I can't get this to work on two different devices.
I will see if I can switch to the Arduino 8266 core.
-
I downloaded Firefox 45.0 for linux and I got much further. Is there a version that is known to work?
I was able to where it was updating the oak and it told me the next update would be in 60 seconds. The problem, the oak SSID went offline and was unable to finish?
I tried it again and it got to the same spot, I tried it on the second device and it was exactly the same.
If I had a know working version of Firefox I could just do them all and revert back to the latest browser.
-
Too bad I can't edit the page. I should probably say that during the update the led was blinking in the rapid 3 blink mode.
-
I tried it from scratch on a third oak. I rebooted the machine and I only used the Firefox 45.0 browser.
I was able to get connected and start the download to the oak. At 41 seconds remaining the wifi became disconnected and the oak was blinking with the rapid 3 blink scenario.
After the 60 seconds I tried to connect back to the acorn wifi and it would spin for a few seconds and then announce it is disconnected. Once the oak is flashing the three rapid flashed it cannot reconnect.
Could it be something with my network?
-
I have thought about my second project and I do need to use the Particle Cloud. I was narrow minded and only thinking about the current project.
I have two projects I want to use the Oak for. First, the current project, is a Brewery Controller where the oak controls the brew kettle using an DS18B20 temperature sensor, a recirculation fan, and a hot water heater element. It connects to the Brew Console over wifi which is an NVIDIA Jetson TK1. The original project connected them via I2C, but since I had the Oak, why not wifi.
The Second project is a Brew Fermentation Chamber. I can ferment 6 beers simultaneously and I want each fermentation to be individually controlled. If I do this correct, I can look at the fermentation progress when I am bored at work.
So, I need to figure this out if possible.
-
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 (http://digistump.com/wiki/oak/tutorials/troubleshooting), it looks like the update has actually loaded, and everything should be fine... perhaps just a manual claim (http://digistump.com/wiki/oak/tutorials/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.
-
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!
-
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...
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...
%ESPTOOL% --baud 115200 --port COM%COMPort% read_flash 0x000000 0x400000 oak_backup.img
(ESPTOOL=esptool.exe and COMPort=3)
-
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.
-
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.
-
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?
-
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.
-
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?
-
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 (https://digistump.com/wiki/oak/tutorials/serial_through_arduino)) 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 (https://digistump.com/wiki/oak/tutorials/serialfirmware) 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!
-
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.
-
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 (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 (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.
-
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.
-
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 (http://digistump.com/wiki/oak/tutorials/pinout#oak_pin_to_esp8266_gpio_mapping)... 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.
find / -name "esptool*" 2>/dev/null
-
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?
-
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 (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?
-
Hm, I'll have a look at that in the morning. You're obviously getting closer... now the output is looking like it simply isn't talking to the ESP8266... as I'm pretty sure the last two lines are the same error you'll get if the ESP8266 isn't plugged into the usb-serial.
But I think you were probably right, in it was initially a problem with the boards.txt from that other article, as that was needed for pre ESP8266 Arduino 2.4.0, as 2.4.0 includes the DigiStump Oak board option as standard. I'm wondering if there is something still not quite right, as I didn't need to modify the boards.txt on mine at all, so perhaps there is still something boards.txt related wrong, or perhaps some other part of the configuration messed up.
-
Are you using windows or linux?
if you look in the file ~/.arduino15/packages/esp8266/hardware/esp82266/2.4.0/boards.txt
is there a property?
oak.upload.resetmethod
-
I miraculously got it to work this morning. Sometimes I wish I wasn't so stupid :(. You said it looks like arduino wasn't connected to the oak so I thought, what do I have to loose, so I just switched Rx,Tx and it uploads the script.
Trouble is, it doesn't seem to work consistently, more then likely not an oak problem.
Archiving built core (caching) in: /tmp/arduino_cache_451701/core/core_esp8266_esp8266_oak_CpuFrequency_80,FlashSize_4M1M,LwIPVariant_v2mss536,Debug_Disabled,DebugLevel_None____,UploadSpeed_230400_87c8508b9b5cd798698478194118aa71.a
Sketch uses 255243 bytes (24%) of program storage space. Maximum is 1044464 bytes.
Global variables use 33328 bytes (40%) of dynamic memory, leaving 48592 bytes for local variables. Maximum is 81920 bytes.
/home/ray/.arduino15/packages/esp8266/tools/esptool/0.4.12/esptool -vv -cd ck -cb 230400 -cp /dev/ttyUSB0 -ca 0x00000 -cf /tmp/arduino_build_942862/TrialOne.ino.bin
the arduino hangs here with Uploading... in the green bar between the sketch window and the output window.
I press Upload again and again and it hangs same place. If I unplug the usb I unable to connect to ttyUSB0. To get it to work I have to unplug usb for about half minute.
Anyway I have my DS1820B demo program working..
-
He he... it happens to everyone ... at least it's working now ;) Gets even more interesting when you have USB to serial devices that note the pins as RXD and TXD, and you have to remember if the TX 'Device' is the UART or the device on the other end :-O :-/
I work on both Linux and Windows, so when you said Linux I switched over to that for consistency. I just realised on my Linux install when updating the Arduino IDE and checking everything was up to date that I was running the RC2 pre-release of v2.4.0, for which the Digistump Oak setting worked just fine, but the release 2.4.0 gave the same error message for which you edited boards.txt for...
Arduino: 1.8.5 (Linux), Board: "DigiStump Oak, 80 MHz, 4M (1M SPIFFS), v2 Prebuilt (MSS=536), Disabled, None, 921600"
setting board to {upload.resetmethod}
error: unknown board: {upload.resetmethod}
known boards are: none ck wifio nodemcu
the selected serial port known boards are: none ck wifio nodemcu
does not exist or your board is not connected
I then added to the following to the boards.txt to resolve it. I set it to none, instead of ck, because the oak doesn't have an auto-reset-for-programming option, which is why you have to have P2 connected to ground when powering it up (you can release the jumper once it's powered up, so I usually put a momentary press button on my builds connected to P2 to make serial programming easy, and also use the switch once a program has booted up if it has any user interaction.
oak.upload.resetmethod=none
I'll do a PR against the ESP8266 and get them to fix that (edit: it was fixed in a commit three days ago, so will be there in the next release), and also change the case of the board name... it's supposed to be Digistump, not DigiStump...
Oh, and I see why the pin mapping is out... when Christopher added the mapping, he stuck with the P1, P2 naming... so if you use the P1 for the blink sketch, it will properly map to that pin on the Oak (ESP8266 GPIO 5). The full list of pin definitions you can use is here (https://github.com/esp8266/Arduino/blob/2.4.0-rc2/variants/oak/pins_arduino.h).
I'll link a full compile and upload log (https://pastebin.com/JZweNLKP) (verbose output) of the un-modified blink sketch for comparison (too long to include in post).
For the intermittent upload issues, try lowering the upload speed to 115200, although AFAIK that only needs changing if uploads fail during the upload process... transferring too fast for UART device or noise present. Otherwise, if you need to unplug it for a while, maybe there's a problem with your USB port or the UART device... Anyway, as you said, it's working now...