Programming an Oak over Serial

[PeterF]

Hi guys,

I've started putting fattening up the wiki article for Uploading a program over Serial as I noticed the heading was there, but no content yet, and have hit a small snag... my Oak won't co-operate (PBKAC error perhaps? ).

I've installed Python and PySerial, and that seems to be working ok. I can get the Oak to appear to program, but it then gives me the following error on Particle, and sits in triple blink config mode. I am connecting RX to TX, TX to RX, and GND to GND, and P2 to GND. Is there anything else I should be doing? It seems to be programming, as it goes through the process of erasing and writing to flash, and upload finishes without any errors, but I'm sure I'm doing something wrong here.

Code: [Select]

oak/devices/stderr                       Config Mode
Any thoughts on this Erik, or anyone else who has been brave enough to try Serial programming?

[cpetito]

At the risk of stating the obvious and I not sure if it's necessary because I do always do it, but is is Pin2 ungrounded when the Oak reboots after flashing?

Serial programming works fine for me.  Both to reflash the firmware and my sketch.  Both with the Ardunio IDE serial programming option and the OAK CLI tool.

[PeterF]

Feel free to state the obvious any time cpetito... you just never know if it is the problem

In this case, no, I ground P2 when powering up the Oak, and then program it, and then pull the jumper and power cycle it. Each time for me it has been just falling back to config mode, so I'm sure there is something simple I am missing. I haven't had any issues with re-flashing the firmware (aka OakRestore) at any point, so this surprised me.

When I was looking at the esptool.py code, I saw references to DTR and RTS, and was wondering if I had to connect them also, but on second thoughts, I thing that is for replacing the bootloader entirely. But just to be clear, this is the process I follow.

Code: [Select]

            # issue reset-to-bootloader:
            # RTS = either CH_PD or nRESET (both active low = chip in reset)
            # DTR = GPIO0 (active low = boot to flasher)

I connect CH340 RX to Oak TX, CH430 TX to Oak RX, and CH430 GND to GND. I then use another GND on the Oak to pull down P2. I then power up the oak using the MicroUSB connector. I then program via the Arduino IDE set to Upload using Serial. I don't get any error messages from the Arduino IDE, but I do get the triple blink pattern from the oak immediately after loading the firmware. I pull the P2/GND jumper, and power cycle the Oak. Makes no difference. I have just run through the config process, and looks like it had forgotten it's wireless credentials. Fixed that up, and I don't get the triple blink / config error now, but oak is now not doing anything except connect to the wifi. Uploaded the test sketch again, and no change there.

Looks like my Oak is giving me a hint to stop procrastinating and get back to my studies! lol

Pete

Test sketch that i usually use for first OTA programming test:

Code: [Select]

void setup()
{
  pinMode(1,OUTPUT);
  digitalWrite(1,LOW);
}

void loop()
{
  digitalWrite(1,HIGH);
  delay(100);
  digitalWrite(1,LOW);
  delay(100);
 
  digitalWrite(1,HIGH);
  delay(100);
  digitalWrite(1,LOW);
  delay(1700);
}


[digistump]

A few important things about serial programming:

You should do an OakRestore before switching over to using serial programming - this is because the OakRestore procedure resets the bootloader table so that the bootloader boots from Rom Slot 0 - the serial upload always uploads there. If you don't do this then it might be booting say slot 3 but your putting the new code in 0.

Pin 2 must be GNDed before power up - sounds like you have that handled.

RTS/DTR is not used at all

Make sure you have TX to RX and RX to TX and GND to GND (Serial adapter to Oak) with very good connections, especially the GND.

[PeterF]

Ah ha! That was it Erik... should have known better after our discussion before about how the slots work on the oak, and moving the pointer for the active slot!

I did an OakRestore in as far as running the esptool command as below, power cycling with the P2<>GND jumper removed, and then powering back up with the P2<>GND jumper connected again, and programming via the Arduino IDE. My little doubleBlinky program runs, but there is more than a 1700ms delay between cycles... more like 10 seconds, and the device goes offline and online on particle after a double blink. Any thoughts? Should I have run through config process again, instead of just flashing my own code after running the esptool command?

Code: [Select]

esptool --baud 115200 --port COM4 write_flash -fs 32m 0x1000 blank.bin 0x2000 oaksetup_restore.bin 0x0081000 oakupdate_restore.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
A little later on: After a few minutes of dithering... the Oak started running the double blink without any issue... it seems to have resolved it's gremlin on it's own. I power cycled it since it had settled down, and it started up perfectly. However, serial upload program #2 ("now with 2.5 times the blinkyness!") doesn't seem to want to settle down and run normally at all, so it is a strange gremlin. I added some serial messages, and whilst Particle is saying the Oak is disconnecting and connecting, the Oak isn't rebooting - it runs setup() once, and runs loop with a bit of hang between each run, corresponding with the connect and disconnect. And again, as I write this, after another power cycle and a minute of dithering, it is running perfectly. I think I will chalk it up to wifi gremlin and call it a night!

Pete

[digistump]

That delay would be it attempting to reconnect to Particle at the end of each loop - but it sounds like it is failing/losing the connection shortly after it connects.

[PeterF]

Ok, that makes sense. So the particle connection maintenance is done at the end of each loop, and once the oak has gotten its act together, connection is no longer an issue, and it behaves. Now to work out why Serial updating seems to scramble it more... or is it the fact I moved my Wifi from Ch1 to 3 yesterday? Although two other Oaks which I OTA programmed a few days ago and haven't touched since are running perfectly - no reconnect hiccups or anything. Will do another OakRestore and OTA program this Oak to make sure it isn't a temperamental one.

[szalap]

Reviving this old topic, as I'd prefer all the information to be in one place.

So I've finally given up on using Particle OTA (unreliable, constant timeouts, failed uploads etc.) and decided to program Oaks through serial port.

Everything seems to work properly, Oak connects to WiFi, but if I set some pins (other than 3,4,5) to OUTPUT mode f.e. Pin 7 or 8, then Oak reports rst cause with a variation of boot mode like (1,6) or (3,6). Something similar to this: https://github.com/esp8266/Arduino/issues/2829
What should I do to make it work? Is there a need for pull-up/pull-down on some pins?

[PeterF]

There's generally no need for any pins to be held high or low for it to "just work". But there are pins to be wary of when booting.
http://digistump.com/wiki/oak/tutorials/pinout#general_notes

However, I hadn't seen it have any issues with resetting when setting pin mode. 

Are you still using Digistump Oak board support (but serial instead of wifi/particle), or did you ditch it completely and move over to the official ESP8266 Arduino board package?