OAK Restarting - FW v1.0.5

[asantos]

Hi,

My OAK had FW 1.0.0 and sudenly it no longer sent events to Particle.io. I decided it was a good time to perform the FW upgrade to v1.0.5
I have connected de OAK to my FTDI and the executed the following like stated in https://github.com/digistump/OakRestore

Code: [Select]

esptool --baud 115200 --port YOUR_COM_PORT write_flash -fs 32m 0x1000 blank.bin 0x2000 firmware_v1.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
The firmware_v1.bin I set was the one from 09-Jul-2016

The upgrade process went smoothly.
Then I have started the SofAP configuration, after finishing the OAK reboots, but the led is giving the 3 blinks every time.
And the ACRON-xxx SSID is still broadcasting.
I think the OAK is starting connecting to Particle, because the last_heard e always incrementing, but then start transmitting the ACRON-xxx SSID, the restarting updating the last_heard and continuing.

Can anyone help me with this issue?

Best Regards,
André

[exeng]

The rapid 3 blinks is a good sign. You should be able to upload whatever sketch you were running before the FW upgrade. As it stands, your Oak is in safe mode.
Have you tried to upload you sketch via the Arduino IDE?

[asantos]

Hi,

I have tried to upload a simple sketch that makes the led blink but it failed. I have installed the add on on android studio for 1.0.5 and installed the most recent version of oakcli. But after compiling the upload of the sketch via OTA fails, and gives no error 

How can I debug this?

Thanks,
André

[PeterF]

No error at all? So it indicates the upload was successful?

If you do a update via serial, you don't seem to need to reconfigure the Oak with SoftAP - it still seems to remember which access point it is supposed to connect to. However, it will still go into safe mode (the triple blink pattern) and report (on particle) that it is in config mode, and that there is no user rom. It is basically waiting for it's first program. If you upload a program then, and you haven't power cycled the Oak since you initiated the serial upload, it seems to freeze  on power up. All I've done then is remove the power, wait a few seconds, and power it up again. Don't have any issues after that first power up. I think after doing the serial update, it is probably better to manually power cycle it, and then it wouldn't be an issue.

If you open up OakTerm, does it report that your Oak is online and in config mode with no user rom? You should also see messages from spark/status indicating that flashing has started when you trigger uploading of a program. If it says it has failed on OakTerm/Particle then the upload should be successful (known bug on the Particle end). OakCLI on the other hand should report success / that the Oak is rebooting. I'd try to upload one or two more times with a power cycle in between. Watch on Oakterm for the message indicating that the Oak is online, and upload your blink sketch.

[asantos]

Hi,

When I have said "upload of the sketch via OTA fails, and gives no error" I meant that besides a simple message saying it failed, it gives no other useful information.

These are the steps I have taken:

Power up the Oak
Oak always shows the 3 blink pattern
I have performed the process so Oak could connect to the AP.
Oak apparently connects successfully to the AP, at lest once and gets an IP address

Code: [Select]

Ago 04 11:30:14 fosters dnsmasq-dhcp[3837]: DHCPDISCOVER(wlp2s0) 5c:cf:7f:0b:53:a7
Ago 04 11:30:14 fosters dnsmasq-dhcp[3837]: DHCPOFFER(wlp2s0) 10.42.0.88 5c:cf:7f:0b:53:a7
Ago 04 11:30:14 fosters dnsmasq-dhcp[3837]: DHCPREQUEST(wlp2s0) 10.42.0.88 5c:cf:7f:0b:53:a7
Ago 04 11:30:14 fosters dnsmasq-dhcp[3837]: DHCPACK(wlp2s0) 10.42.0.88 5c:cf:7f:0b:53:a7 ESP_0B53A7
The OakTerm does not report anything, and so does the Particle Console

I have also monitored the console for any event, and nothing:

Code: [Select]

curl https://api.particle.io/v1/devices/events?access_token=27XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX72
:ok


Apparently it somehow connects periodical to the cloud, but the SSID ACRON-xxx ia almost always available.

Code: [Select]

[asantos@fosters ~]$ curl https://api.particle.io/v1/devices/d95704000904345f018fc079?access_token=27XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX72
{
  "id": "d9XXXXXXXXXXXXXXXXXXXX79",
  "name": "Luz_Sala",
  "last_app": null,
  "last_ip_address": "213.228.181.57",
  "last_heard": "2016-08-04T10:30:16.620Z",
  "product_id": 82,
  "connected": false,
  "platform_id": 82,
  "cellular": false,
  "status": "normal",
  "pinned_build_target": "1.0.5",
  "variables": null,
  "functions": null
}

[asantos@fosters ~]$ curl https://api.particle.io/v1/devices/d9XXXXXXXXXXXXXXXXXXXX79?access_token=27XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX72
{
  "id": "d9XXXXXXXXXXXXXXXXXXXX79",
  "name": "Luz_Sala",
  "last_app": null,
  "last_ip_address": "213.228.181.57",
  "last_heard": "2016-08-04T10:46:33.693Z",
  "product_id": 82,
  "connected": false,
  "platform_id": 82,
  "cellular": false,
  "status": "normal",
  "pinned_build_target": "1.0.5",
  "variables": null,
  "functions": null
}

Anyway, I tried to upload a skecth, and this is the error I get:

Code: [Select]

Ago 04 11:32:15 fosters arduino-arduinoide.desktop[406]: Sketch uses 261,106 bytes (25%) of program storage space. Maximum is 1,040,368 bytes.
Ago 04 11:32:15 fosters arduino-arduinoide.desktop[406]: Global variables use 51,184 bytes (62%) of dynamic memory, leaving 30,736 bytes for local variables. Maximum is 81,920 bytes.
Ago 04 11:32:15 fosters arduino-arduinoide.desktop[406]: /home/asantos/.arduino15/packages/digistump/tools/oakcli/1.0.2/oak /tmp/build2d65158234e2488adff50dfced5608f4.tmp/sketch_particleio_led.ino.bin
Ago 04 11:32:16 fosters arduino-arduinoide.desktop[406]: OakCLI tool version 1.0.2
Ago 04 11:32:17 fosters arduino-arduinoide.desktop[406]: Using config file at: /home/asantos/.oak/config.json
Ago 04 11:32:17 fosters arduino-arduinoide.desktop[406]: Sending file to cloud, to flash Luz_Sala (Device ID: d9XXXXXXXXXXXXXXXXXXXX79)
Ago 04 11:32:18 fosters arduino-arduinoide.desktop[406]: Error : An error occurred while flashing the device:
What else can I do to debug this issue?

Thanks,
André

[PeterF]

Ok, thanks for clarifying that André.

When it is in config mode, that is the expected behaviour - it connects to your configured access point to await for an upload, and also runs it's own so it can be configured if needed. It is running in dual access point and client mode.

So you don't get anything like the attached screenshot with you use OakTerm? It *should* say that the device is online, in config mode, and that there is no user rom... And on the Particle Console, does it show a pulsing blue orb next to the device when it is online?

One thing you could check is to double check what config mode firmware version is on the Oak... Connect to the Oaks Acorn access point, and go to 192.168.0.1/info in a web browser, and check what the version_string is. If that isn't 1.0.5, you'll want to re-download that firmware_v1.bin file, as it's the wrong version. Only other thing I can think to check this early on is what channel is your wifi running on? If it is channel 1, can you move it do another channel, as there is the possibility the Oaks access point (which broadcasts on channel 1) is not allowing it to hold the connection well enough for a firmware download. However, since it looks like from your log that it

Other than that, it might be necessary to run the firmware update (esptool) command again, as it would seem there is something wrong, since it is connecting to the internet/particle, but isn't responding properly - in fact the upload seemed to fail instantly (went from sending to failed in about a second), which I haven't seen before... it usually takes a while to spit the dummy, or at least make a little progress (you see several dots after 'Flashing') before it falls over for some reason or another.

[asantos]

Hi,

I wasn't aware of that caveat, regarding the AP dual mode, in client and access mode at the same time.
No, I do not get what you get in the OakTerm.
The two timestamps on the screen have been two  empty send data that I have performed. No messages from Oak
On OakTerm device shows has offline but with very very recent last_heard time...
On the Particle Console it show the pulsating blue orb.

Below is the output of the firmware version, and it is running 1.0.5

Code: [Select]

curl http://192.168.0.1/info
{"id":"d9XXXXXXXXXXXXXXXXXXXX79","claimed":1,"claim_code":"","server_address_type":1,"server_address_domain":"device.spark.io","system_version":10,"version_string":"1.0.5","meta_id":0,"meta_data":"","first_update_domain":"oakota.digistump.com","first_update_url":"/firmware/firmware_v1.bin","first_update_fingerprint":"98 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 95"}
I have changed the AP to channel 11, but the Oak SSID also moves to the same channel... See attached image. forsters.vi.pt is the AP name. It still shows has off-line, and no data is sent to OakTerm.


Tks,
André

[asantos]

HI,

I have tried another AP, but got the same behavior.
I have connected the FTDI adapter during boot, but I believe the Serial is off, and not giving any output.

I have also performed a wireshark trace on the PC while the sketch was being uploaded, and could not find anything strange :S
What I saw was a first TCP/SSL stream that was terminated by Spark servers, and then another TCP/SSL stream this with much more packets also being terminated by Spark/Particle server.

I don't know what else I can do to put Oak once again in a working state

Tks

[PeterF]

Strange... I thought the config mode was configured as CH1... must be something to do with the dual client/ap mode.

If you connect at 74880 baud to the Oak, you should *always* get some output when you connect the power, as the bootloader starts up at that rather odd baud rate.

Code: [Select]

ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 3632, room 16
tail 0
chksum 0xc0
load 0x3ffe8000, len 352, room 8
tail 8
chksum 0x82
csum 0x82

OakBoot v1 - N,BP,4
However, yes, otherwise you won't get any output, as by default the oak config mode is compiled with serial messages turned off. Otherwise you would connect at 115200 baud, and it would give you info at that baud rate. Only way you'll get output now is if your sketch has serial output and is running (except for the bootloader at 74880 baud).

Looking like this is either an error on the particle end, or maybe the Oak needs a reflash beat it into submission.

[emardee]

I think I read it is locked to channel 1 JUST for initial firmware loading... hence those struggling to get their firmware loaded sometimes find moving their AP off channel 1 helps with unit that won't work out of the box. The issue was a weak boot firmware from factory.... but should be no issues with that once v1.0.5 is loaded. Hence v1.0.5 can run on any channel. That was my understanding of the situation, but I might be wrong!

[PeterF]

No, that is probably right... I was partly basing that of the OTA update code for the ESP8266, so will be out of date info for the Oak anyway. Makes sense too, as the initial firmware was only concerned with updating, whereas config mode is in dual ap/client mode, so will probably follow the channel of the configured ap.

[kh]

Strange... I thought the config mode was configured as CH1... must be something to do with the dual client/ap mode.

The ESP8266 can only operate on one channel at a time, so when in dual client/ap mode (i.e. in config mode after setting up your SSID and password), the acorn AP will always use the same channel as the AP the Oak is connected to.

I have also performed a wireshark trace on the PC while the sketch was being uploaded, and could not find anything strange :S
What I saw was a first TCP/SSL stream that was terminated by Spark servers, and then another TCP/SSL stream this with much more packets also being terminated by Spark/Particle server.

It's possible you're seeing the same issue that I and others have seen in the past. I did similar Wireshark captures for my device when I was having this issue and analyzed the communications, so I'd be happy to take a look at your capture of you're okay with providing it. If so, send it as a private message attachment if that's possible. If not, we can exchange email addresses via private message.

The other useful tool to debug cloud communications is to uncomment the #define DEBUG_SETUP line in particle_globals.h as PeterF alluded to. See my post on this for more info.

[asantos]

Hi,

During the weekend I tried to debug the Oak, via WireShark and via Serial.
Strange things have happened

While doing a tcpdump in both interfaces to catch  traffic from oakcli to spark and from spark to Oak, the skecth has stated to upload, and midway aborted with the bellow error:

Code: [Select]

Ago 05 21:14:42 fosters arduino-arduinoide.desktop[7226]: /home/asantos/.arduino15/packages/digistump/tools/oakcli/1.0.2/oak /tmp/buildbe9c3a8c84f3094ac65d1c1af6cf9e42.tmp/Start.ino.bin
Ago 05 21:14:43 fosters arduino-arduinoide.desktop[7226]: OakCLI tool version 1.0.2
Ago 05 21:14:44 fosters arduino-arduinoide.desktop[7226]: Using config file at: /home/asantos/.oak/config.json
Ago 05 21:14:44 fosters arduino-arduinoide.desktop[7226]: Sending file to cloud, to flash Luz_Sala (Device ID: d95704000904345f018fc079)
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: Flashing...nexe.js:43036
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: var eventData = data.data.trim();
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: ^
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: TypeError: Cannot read property 'data' of null
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: at nexe.js:43036:37
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: at Spark.emitAndCallback (nexe.js:31037:42)
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: at null.<anonymous> (nexe.js:31055:10)
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: at Request.self.callback (nexe.js:28482:22)
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: at Request.emit (events.js:110:17)
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: at Request.<anonymous> (nexe.js:29349:10)
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: at Request.emit (events.js:129:20)
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: at IncomingMessage.<anonymous> (nexe.js:29270:12)
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: at IncomingMessage.emit (events.js:129:20)
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: at _stream_readable.js:908:16
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: the selected serial port     at _stream_readable.js:908:16
Ago 05 21:15:45 fosters arduino-arduinoide.desktop[7226]: does not exist or your board is not connected

After this the same error has happened for all the tries to uploading a skecth.

Code: [Select]

Error : An error occurred while flashing the device:
After this I have tried to connect via serial.
And all I have got was this output that seems like a core dump, or similar...

Code: [Select]

Fatal exception (0):
epc1=0x40225ab0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):
epc1=0x40225ab0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):
epc1=0x40225ab0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):
And today I connected the Oak, and only the Power led is lit. Led on Pin 1 is always of.
I have started the Oak with P1 to GND and the remove after 3 secounds, but nothing happens

I really do not know what to do 



Best Regards,

[PeterF]

Ok, that explains why the Oak won't go into safe mode now. When the fatal exception error has happened for me (which has only triggered by trying the Particle Build firmware upload so far as it's still a work in progress), something has gone wrong with the upload process, and it has wiped out both safe mode and the user rom, leaving an Oak that will boot but that is all - it can't do anything without the firmware being manually restored.

You'll need to do an forced serial update, or use the OakRestore firmware and do the first update via the wireless. It's much easier to do the forced serial update, as that should restore the Oak and get the current firmware on it in one hit.

[saperlot]

Just posted this on the error on the Topic: Error : An error occurred while flashing the device

But this seems to be very similar:

I have same the problems since a few days.

So i did a restore over serial (took the latest firmware_v1.bin form 09-Jul-2016 13:40).
Now i see the device is up on particle.
When i try to flash the simple blink example it starts to flash (oak blinks).
After a few seconds i see the OAK stops blinking, but the IDE still shows Flashing.
Oak is going back to "fresh install" blinking and shows on particle "No user rom found".
Then the IDE tells me "Error : Oak is back online before flash sucessfull."

The Oak clearly gets restarting within the flashing process. I can not get any new FW on it.

OakCli: 1.0.2
OakArduino package: 1.0.5