Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stuck in OakBoot loop #42

Closed
emcniece opened this issue Feb 14, 2016 · 8 comments
Closed

Stuck in OakBoot loop #42

emcniece opened this issue Feb 14, 2016 · 8 comments

Comments

@emcniece
Copy link

Just trying to get started with the 1.6.5 firmware, following the instructions from #30 with a few hurdles along the way. I am finally able to flash the device over serial, but the "Start" example won't run properly - the device gets stuck in a loop.

After flashing and power cycling, the serial monitor reveals this dump (endlessly repeating every ~500ms):

OakBoot v1 - N,BU,0


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

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

This seems to appear regardless of what the sketch entails, and the LED on P1 doesn't flash. Anybody know what this means?

@digistump
Copy link
Collaborator

Strange - I certainly am not able to duplicate but a few thoughts on what might be causing it:

Did you run the OakRestore command first from the instructions in #30 - that also clears out the bootloader config. That doesn't appear to be the issue here though because it is booting to 0 which is where the serial uploader places it.

Has the Oak already been registered and claimed on the Particle cloud - it should be before you do this.

Has the Oak been configured to use your WiFi already - it should be before you do this.

You can uncomment #DEBUG_SETUP in particle_globals.h to get a whole bunch of debug info on the serial monitor - it might show something.

If you did uncomment #DEBUG_SETUP already then you absolutely have to have Serial.begin(115200); be the first line of your sketch in setup()

Let me know if any or none of those help, happy to dig further, thanks for trying to get this to work!

@emcniece
Copy link
Author

The OakRestore process was executed without error! However, the device has not yet been registered/claimed and it hasn't been configured for Wifi! Thanks for the tips, will update with progress.

@emcniece
Copy link
Author

Tried enabling #DEBUG_SETUP in C:\Users\YourUserName\AppData\Roaming\Arduino15\packages\digistump\hardware\oak\0.9.3\cores\oak\OakParticle\particle_globals.h and added Serial.start(115200); to first line in void setup(){} - no difference in serial dump

As advised, attempting to add wifi creds to the device and register is on the Particle network. Device is not showing up as a wifi AP, can't find ACORN-xxxx AP in lists.

Swapping out to a new device as this one may be useless for now. Can't find instructions to configure device for networks from within the bootloader.

update: next device won't accept the update through https://github.com/digistump/OakSoftAP. Stalled for now. Is there any way to register a device and add wifi credentials via serial/uart/Arduino GUI?

@digistump
Copy link
Collaborator

Sorry missed this one - you can set the wifi settings with the SoftAP config app and then get the device-id at 192.168.0.1/device-id (while connected to the Oak) and add that manually in the Particle IDE->Devices tab - but the Oak has to be connected to the cloud when you do that, so you'd still need to get the start sketch or similar running on it before you can claim it.

Interested to hear if you can reproduce this with the second one and/or a clean install... seems very strange as most of my development follows the steps in #30

If you get another chance to try it let me know how it goes!

@pauln
Copy link

pauln commented Feb 29, 2016

This seems to match what I'm seeing with the current firmware (either via OTA or manual update via serial) pretty closely, as per https://digistump.com/board/index.php/topic,2034.msg9260.html#msg9260 - no ACORN-XXXX AP is present. The one difference is that I'm not seeing quite such a quick boot loop: when I plug it in to power, it spots out the following:

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,BU,0

And then, a minute or two later, it appears to reboot, giving an almost identical message (boot mode changed from 3,6 to 3.0), which matches the message reported above exactly. Is there any further debugging which we can run on Oaks in this state to help figure out what's going wrong? Or perhaps a list of serial commands which can be used to poke and prod the Oak?

@pauln
Copy link

pauln commented Feb 29, 2016

Further to the above:

  • When I first tried to set this Oak up via OakSoftAP, I got through the connection to my network; the Oak connected to my network, downloaded the initial update, started the "new" blink pattern... but didn't start the ACORN-XXXX hotspot for me to connect to in order to continue the OakSoftAP process
  • I've since tried using OakRestore followed by a fresh run through OakSoftAP - multiple times
  • Having landed in the same spot each time, I then tried using the instructions in the OakRestore readme to flash the initial update via serial, which also landed me in the same spot

I've just noticed that the Oak actually appears to be connecting briefly to my home network on boot, but rapidly disconnects (without any serial output). I've just checked my router's logs, and it's going through a full DHCP discover/offer/request/ack cycle each time the Oak boots - both on initial power up and each time it reboots itself - but appears to disconnect pretty much immediately thereafter, as if I try to request /device-id when I see it connect, the request simply times out (and checking my router's connected devices list reveals that the Oak is no longer connected).

Another oddity: sometimes, the boot messages appear at 74880 bps, and other times at 15200 bps. Often, it'll start at one rate when I power it up, then switch to the other seemingly arbitrarily after a couple of reboots. This makes it a little awkward to monitor on an ongoing basis - after a couple of readable boots, it'll generate a gibberish boot log because it's switched bit rate.

@pauln
Copy link

pauln commented Mar 2, 2016

My issue appears to have been resolved by the Beta 5 release. Thanks for all the hard work!

@digistump
Copy link
Collaborator

This should have been resolved by the last few releases, closing, feel free to reopen if it persists

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants