Digistump Forums
The Oak by Digistump => Oak Support => Topic started by: andytt11 on February 06, 2016, 04:12:48 pm
-
I was successful at uploading the blink demo but now it will not take any new code. There is the power light but nothing else. It also does not transmit ACORN-XXXXXX.
-
Not a good sign. Do you have a 3.3v FTDI board?
I just fixed the same problem on one of mine. It's an easy fix, just need the serial to usb converter. They're under $10 on amazon if you don't have one.
This is how you do it --> https://github.com/digistump/OakRestore
This is the board I used if you need to get one -->
http://smile.amazon.com/gp/product/B012YUANZK?psc=1&redirect=true&ref_=oh_aui_detailpage_o03_s00
-
If anyone experiences this and has a serial adapter I would be most grateful for a memory dump of the Oak before you restore it - so we can try to see what is going wrong, or at the least taking a look at the serial output of the Oak
The command to dump the whole flash is:
esptool.py --baud 115200 --port COMX read_flash 0x000000 0x400000 flash_dump_full.bin
Where COMX is your COM PORT
You can email it to me at support@digistump.com
Thanks,
Erik
-
No FTDI. I'll pick one up and try to recover it along with a dump. I am using a surface pro 2 tablet. I had trouble even seeing the oak broadcast when I fist set it up. Didn't know if that additional info helps.
-
I had better luck getting my board to see my wifi APs at home by shielding the board a bit. Sitting on it worked nicely.
I know this sounds crazy but it's almost like the wifi module ignores APs over a certain signal strength.
-
I think I may be able to help as I also have a seemingly bricked unit with similar behaviour, but cannot seem to connect to Oak at all. This is what I get:
PS D:\work\arduino\Oak\OAkRestore> ./esptool.exe --baud 115200 --port COM5 read_flash 0x000000 0x400000 flash_dump_full.
bin
Connecting...
A fatal error occurred: Failed to connect to ESP8266
Question : Do I need to connect the Reset Pin of the Oak to GND? (Your instructions says Pin2, and I assume this does not refer to IO pin 2, but Reset?)
The reason why I used the exe and not Python directly is because the Python method also gave me another prolem. I think that if you want to use Python, then it is important that you install the correct version, but the instructions is not specific about this either.
I installed Python 3.5.1 and it does not like the print statement without parenthesis. (I'm no Python expert, but I think only really old Python versions like Python 2 supports this style)
This is what I get when I use Python.
PS D:\work\arduino\Oak\OakRestore> python esptool.py --baud 115200 --port COM5 write_flash -fs 32m 0x1000 blank.bin 0x20
00 oaksetup_restore.bin 0x0081000 oakupdate_restore.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
File "esptool.py", line 149
print 'Connecting...'
^
SyntaxError: Missing parentheses in call to 'print'
[code]
-
Pin 2 as labeled on the Oak PCB needs to be connected to GND to enter Serial bootloader mode, connect that and connect the Oak to the serial adapter (rx to tx, tx to rx), then power up the Oak
The absolute best thing you could give me from the bricked unit is the exact sketch that it bricked under, description of conditions and OS
Thanks!
-
I'm still confused. I can not see any pin labelled Pin 2 on my Oak board. I think it has a different name as can be seen in the image below.
(http://digispark.s3.amazonaws.com/OakByDigistump.png)
-
werner, yes, the SCL pin next to RX.
(Verbose in case its helpful to others)
TX (Pin4) on the Oak should be connected to RX TTL cable/adapter
RX (Pin3) on the Oak should be connected to TX on your TTL cable/adapter
One of the GNDs on the Oak should be connected to GND on the TTL cable/adapter
Use a jumper wire to connect SCL (Pin2) on the Oak to GND (plug it into the other free GND)
Also be sure the logic levels for RX/TX on the TTL are 3.3V. (My cheap MicroCenter Inland adapter has a toggle -- the + pin is fixed at 5V regardless but we're only connecting RX and TX and GND so its fine)
-
Thanks. I'm going to give this another go right away. Will let you know how it went.
-
Woohoo! :)
Success, but unfortunately I forgot to do the dump first. But now that I know I can restore it easy enough I won't be scared of bricking it again. Next time I will remember to make the dump and tell you which example sketch caused it.
For info sake of others also doing this, this is what you should see during the restore :
(https://digistump.com/board/index.php?action=dlattach;topic=1995.0;attach=32111;image)
-
Hi,
I bought the same serial adapter in amazon but I cannot flash it this is what I can see, do you know what can i do?
I execute the instruction inside oakrestore-master folder. I connect RXD-TX / TXD-RX / GND TO GND AND SCL TO GND
I use mac-os with Windows 10 in virtual machine Connected to COM3.
This is de message:
A fatal error occurred: Failed to connect to ESP8266
Thanks for helping
-
I would try removing the wire connected to VCC, and powering the Oak via the USB cable, instead of the FTDI board, as it may not be providing enough power to the Oak. Your wiring seems ok. Only other thing I can think of (which you have probably already checked) is the COM port number - that when you look in device manager on the Windows VM that your FTDI board is listed as COM3 under the "Ports (COM & LPT)" category.
Good luck!
-
Hi pfeerick,
I just checked it with external usb power but with the same result. The COM3 is correct because I've checked in devices manager in windows and if I try to change it I can see an error in command prompt and the FTDI led is not blinking.
I've tried with other Oak and it happens the same. I don't know what can i do wrong.
Thanks.
-
Does it make any difference if you swap the TX and RX around?
I haven't used the VM in mac OS before but is the COM port bridged correctly? Because VM's are supposed to be a sandbox, there's supposed to be settings to allow the VM to see the outside world (your Mac OS)
Only asking this because I had the a problem with Serial com with Win XP (VM) trying to communicate to Win 7 (the main OS)
-
No difference If I swap TX and RX, I can see activity in TX serial module pin but not in RX pin.(it looks normal because it seems oak doesn't answer.
About Com port, I have re-installed the original drivers but with the same result, com3 is communicating but something should be wrong with RX.
About VM in mac OS, it looks fine because when I connect the usb I can choose between mac and win10.
I have re-checked the connections hundreds of times but it isn't.
thanks.
-
Sounds like a problem with com port adapter to me. Since it is new, you might have got sent a faulty unit from Amazon possibly.
Have you got anything else you can connect so you can test your com port adapter and check the driver settings are correct?
-
If anyone experiences this and has a serial adapter I would be most grateful for a memory dump of the Oak before you restore it - so we can try to see what is going wrong, or at the least taking a look at the serial output of the Oak
The command to dump the whole flash is:
esptool.py --baud 115200 --port COMX read_flash 0x000000 0x400000 flash_dump_full.bin
Where COMX is your COM PORT
You can email it to me at support@digistump.com
Thanks,
Erik
How long does this take? Because it says: Connecting... Please wait....
Been waiting 5-10 minutes
I tried uploading the LED blink code to particle, and i assume particle tried to upload it to the oak, but instead it just bricked it. Only pwr is on and there's no LED flashing. I also can't see the oak when i scan it on wireless
-
@Blitzfx: That command should start showing some activity almost instantly..., and only takes 2 minutes at most, more like 1 minute. Or at least it did when I used to load the restore firmware!
Did you power up the Oak with Pin 2 connected to GND? I don't think the esptool command works unless you do.
@maximo80: One 'dumb' test to do if you have Arduino or some other terminal program on the VM system, is to just connect the FTDI TX to RX, and see if it echos back whatever you type (i.e. when you type something without TX&RX joined, nothing appears in the Arduino serial terminal but it will when they are joined). Then you know that the RX & TX are working properly on the FTDI board, within the VM. All I can suggest then is use some different jumpers if you can, just in case one is dodgy.
-
It should show some activity, and it does for a little bit.
Here's how i've connected it. And I've connected pin 2 to ground otherwise it just says failed to connect or something like that:
http://i.imgur.com/S5KRP1p.jpg
http://puu.sh/noaCe.png
This is the second time it's bricked when i'm trying to load the "Start" example code. http://puu.sh/noaFM.png
Which setting did you pick in the Arduino IDE? http://puu.sh/noaQD.png
I've followed the instructions on here https://github.com/digistump/OakCore/releases so I'm starting to run out of ideas now.
-------
Well it seems i've bricked it for a 3rd time now.
(http://puu.sh/nody3.png)
The wireless signal isn't being broadcasted from the oak anymore and the LED isn't blinking.
-
Blitzfx, I'm still on v0.9.3 - I never upgraded to v0.9.4, I didn't see it until Erik rolled it back, so never moved to it. So I only have the one entry for the Oak (Oak by Digistump) on my boards menu. I'm running Arduino IDE v1.6.7, and it seems to be playing with my Oak fine when it wants to behave.
Remember to only have Pin 2 grounded when you want to access the config / restore mode - otherwise that would be the cause of your problems.
That is very peculiar that you are having issues that way - it is programming ok, and is rebooting to load your program, but then gets stuck. Might be worth removing v0.9.4 from your Arduino IDE, and rolling back to v0.9.3 if you can? It doesn't look like the package supports multiple versions, and I don't want to break my working config just yet :), so I don't know if you re-install the oak boards package if it will install v0.9.3 again... I'm just wondering if it is something that broke for your setup when the fast OTA updates function was released in v0.9.4??
-
Ah, I didn't realise the v0.9.4 referred to the Arduino IDE board version as well. I thought it was something to do with the http://rawgit.com/digistump/OakSoftAP/master/config.html
I'll downgrade/re-update and give it another try. Not going to use v1.6.7 though. Maybe if it fails again I will.
I also disconnect everything after I restore the oak and plug it into a separate usb power supply.
-
yaaay it works
(http://puu.sh/nortq.png)
but quite a long time to program lol
-
Yay! Success! Yeah, I noticed the same as well. When FastOTA is ready, code uploads should be a lost faster. My setup usually takes about five minutes, sometimes longer, but seems to get there in the end, so not too worried yet!
-
@Blitzfx: That command should start showing some activity almost instantly..., and only takes 2 minutes at most, more like 1 minute. Or at least it did when I used to load the restore firmware!
Did you power up the Oak with Pin 2 connected to GND? I don't think the esptool command works unless you do.
@maximo80: One 'dumb' test to do if you have Arduino or some other terminal program on the VM system, is to just connect the FTDI TX to RX, and see if it echos back whatever you type (i.e. when you type something without TX&RX joined, nothing appears in the Arduino serial terminal but it will when they are joined). Then you know that the RX & TX are working properly on the FTDI board, within the VM. All I can suggest then is use some different jumpers if you can, just in case one is dodgy.
Hi everyone,
I've checked TX/RX in FTDI board and it seems OK, I attach a screenshot on arduino serial monitor and an image of FTDI.
I don't know what to check now. How can I check if Oak TX is working fine?
If I take out the Oak GND from FTDI board GND then TX/RX in FTDI are blinking but with the same error message.
Help please!!! I am desperate
-
It looks like your problem may be in fact the FTDI board, given the message you're getting from the serial console - the “NON GENUINE DEVICE FOUND!” message - as you shouldn't be getting that. I don't expect the esptool is robust enough to remove that message (which is injected into the serial stream by the latest FTDI driver, as FTDI are busy ruining peoples days yet again[1]). See if you can roll back to an earlier driver, or remove the current one and manually install an earlier version. The only thing that you should see in the serial console when TX & RX are looped is what you type and send to it - it should merely echo what you send. Anything else, and it ain't gonna work!
[1] http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/ (http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/)
-
oh my god lol
Poor maximo :P
Where did you buy it? Was it Ebay? It would be nice so everyone else here can avoid that place.
-
lol... hope you mean that seller! eBay is a good place... a nice place... as long as the buyer beware!
If you can't get back to an older driver for the FTDI, grab a CH340 USB to Serial adapter (actually, just get one anyway!!) - even the cheapest ones on eBay now ($1.04 in Australian Dollars - my local currency - http://www.ebay.com.au/itm/Adapter-STC-USB-To-RS232-TTL-CH340G-Converter-Module-replace-PL2303-CP2102-Z3-/131558679211?hash=item1ea18222ab:g:-VQAAOSw9N1VqHym (http://www.ebay.com.au/itm/Adapter-STC-USB-To-RS232-TTL-CH340G-Converter-Module-replace-PL2303-CP2102-Z3-/131558679211?hash=item1ea18222ab:g:-VQAAOSw9N1VqHym)) seems to have a 3.3v option, which you need for the Oak.
-
Thanks pfeerick,
It was exactly what you said, I had to downgrade FTDI drivers as you posted and problem solved.
About second Step to restore OAK ( this is what I read )
This will not restore an Oak that has had its Particle Config overwritten at 0x100000 and 0x201000 - a device where that has occured can be partially restored by this method but then will need its device id set via serial, and you'll need to have recorded it previously. Then connect at 115200 baud and send set\n40\n{"device-id":"123456789012345678901234"}\n where 123456789012345678901234 is replaced by your device-id. You can also send a raw POST to 192.168.0.1/set with the same JSON while connected to the AP of the Oak
I have device id number but I do not understand when it indicates POST to 192.168.0.1/set with or connect to 115200 baud or set\n40\n{"device-id":"123456789012345678901234"}\n
where have I to connect it ? via arduino IDE(serial monitor) or command prompt
Thanks
-
Arduino Serial monitor set to 115200 baud would work for that - you only need to do this step if you overwrote your Oak firmware with some other firmware (like NodeMCU/Arduino ESP8266)
-
As Erik says, you should only need to do that if you overwrite your Oak with some other firmware - it should still be safe in your case though as you were simply giving it a swift kick in the pants to liven it up ;)
Otherwise, you would connect to it via serial at 115200 baud, and send the command "set\n40\n{"device-id":"123456789012345678901234"}\n" (minus the quotes), where the numbers would be your device ID. The POST method when connected to the AP is at bit more complicated.
-
I know it's pedantic and picky, but to remove possible confusion from taking things too literally...
Otherwise, you would connect to it via serial at 115200 baud, and send the command 'set\n40\n{"device-id":"123456789012345678901234"}\n' (minus the single quotes), where the numbers would be your device ID. The POST method when connected to the AP is at bit more complicated.
-
LOL... FAIL!!!! :o Yes, indeed... don't remove all the double quotes! ;D ;D ;D
-
I suffered a grueling [and feels like wasted] day finally getting around to set up my oak. Good lord what a ride. I got the firmware flashed and associated it to particle.io and was even able to start flashing programs. Then arduino started timing out during the "flashing......" phase. Using the particle app on my phone, I could see it wasn't online. I've probably been through the wireless setup more than 25 times today, and regardless of home wifi (WPA2 or open) or phone hotspot, it shows up for a minute or so on the particle dashboard, then goes offline again.
My method to try and get it on wifi again is to jump p1 to gnd and go through the process all over again. Were the errors here related to it just not being on wifi, or did the success of a restore indicate that it was something else?
I don't understand how anything I've done could have overwritten the basic functionality of connecting to wifi and listening to particle!? When i ground p1, it goes into the post-firmware-update flash sequence (3 quick blips, pause, repeat). Any suggestions on how to figure out what in the world is going on?