Installation and Troubleshooting
bdub at June 5th, 2014 01:05 — #4
If that's the case, can't you force a reset on the arduino side... attempt to reprogram from the computer side... then let go of the reset condition?
nonsanity at June 5th, 2014 01:10 — #5
I haven't looked at the pin outs in any great detail yet, but if grounding a reset pin gives me time to start a download, I'll try it.
This may not be due to the running program, the more I think about it, though. The 150 ms sleep SHOULD give the Loader plenty if time to get a command through. The more I think about it, the more I think it might be something with the Loader itself. Some state it's gotten itself into that persists through relaunches and reboots (I tried both). I think I'll try a fresh install of it, though I can't be sure there isn't some broken data file it's reading from somewhere that I don't know about.
Some dev feedback might help in following that lead.
cdunne at June 5th, 2014 01:58 — #6
We're currently working on a feature that will let you reset the bean in case something goes awry (as it has done for you). In the mean time, I've been testing out a similar bug that you're experiencing. To confirm, I had a sketch running that basically blinked rapidly and output via the serial. I could connect to the Bean via the Loader, but I could not load a new (safer) script.
I'm able to consistently replicate this bug, and after some effort I'm able to install a new sketch. I don't have a perfect troubleshooting process yet, but I recommend doing a combination of removing the battery, closing/opening the launcher, connecting to the bean, and trying to install the new sketch. I am certain some order of these actions gets the bean to install a new sketch. I'm not 100% sure it's safe to do things like remove the battery when you're connected (my bean starts to freak out and stop blinking occasionally), so if you want to be safe you can wait for us to release an update.
If you figure out a good troubleshooting process for this issue, be sure to post it!
nonsanity at June 5th, 2014 02:53 — #7
Well, I'm glad to know I'm not seeing things and my first suspicion was right. I'll keep trying—hopefully the 150ms sleep gives me at least a chance. But getting an update out quickly is sure to be important. I bet a lot of people will try out the serial commands without adding any sleep at all... and then they will be in the same boat.
I tried telling it to "update" the firmware, but nothing happened. But I'm already running the latest firmware anyway. Does it check that and do nothing or am I going to have the same difficulty doing that as I have with trying to update the program? I get an "update failed" message with programs, but nothing at all when I try to update.
Would some RF or hardware signal that forces it to switch between the A and B images make a good fallback procedure?
cdunne at June 5th, 2014 03:06 — #8
If your firmware is already up to date, updating it won't really do anything (I think). Furthermore, I found that I couldn't update it anyway, for the same reason I couldn't install the sketch. So when you solve one problem, you solve the other.
Try playing with the turn on/off LED options when you right click your bean. They will give you an indication of what state the bean is in (for me, sometimes they would work and sometimes they wouldn't). My most recent idea of how to fix this issue is to somehow break the loop that the bean runs (can't reliably do this), and then connect to the bean and try the sketch.
@ChrisPTD should be able to offer an answer for your last sentence. Additionally I'll be troubleshooting it more tomorrow, but note that I would be doing the same steps as I suggested you do in my previous post. Again, this would just be a temporary fix until we get our next update out.
ken at June 5th, 2014 10:17 — #9
Here's how I got mine unstuck (due to a serial print problem with a delay of 1, ugh):
I put a jumper wire between the GND and R pins and re-inserted the battery then pressed the refresh button on the Bean Loader (for Mac). The Bean showed up in the list now! I connected. Progress!
I tried to upload a sketch, No go.
I right-clicked the bean entry in the list and got ready to Program Sketch and removed the jumper wire and immediately pressed Program Sketch. It uploaded the sketch and is working and all is good again.
Hope it works for you.
bdub at June 5th, 2014 12:07 — #10
That's exactly what I was describing above Good deal.
nonsanity at June 5th, 2014 15:34 — #11
I've edited the top post to include the solution to this problem, as well as a link to a YouTube video that demonstrates how to unlock your Bean.
bdub at June 5th, 2014 16:12 — #12
Nice video I'm sure that will be helpful a lot down the road.
chrisptd at June 5th, 2014 17:15 — #13
Nice work @Nonsanity. Yep, this will reset the Arduino and trigger the bootloader so you can program the Bean that's loaded with a problematic sketch. We're working on an update so that it's not so easy to pummel the Bean with serial messages, but this works nicely in the interim. Mind if we sticky the post?
nonsanity at June 5th, 2014 17:23 — #14
Please, share. That's what it's there for!
bdwalker1 at June 5th, 2014 18:13 — #16
@Nonsanity, great job on the video. I especially appreciate you leaving in the part where you loaded the locking routine accidentally. I'm sure plenty of people will make that same mistake. They'll appreciate having seen it in the video.
nonsanity at June 5th, 2014 18:18 — #17
@bdwalker1 Yeah, for a moment I considered starting over, but it also let me go over the steps a second time. Repetition helps retention... or so the Teletubbies insisted.
chrisptd at June 5th, 2014 19:20 — #19
This topic is now pinned globally. It will appear at the top of its category and all topic lists until it is unpinned by staff for everyone, or by individual users for themselves.
codeandcircuit at June 6th, 2014 10:23 — #20
I am having this same problem on one of my Beans (no sleep call and Serial output causing it to not be able to reprogram.) So I look forward to trying this solution.
FWIW, I got into this situation after modifying the AccelerationReading example to have some Serial.prints. That example code uses a delay instead of Bean.sleep().
bdub at June 6th, 2014 11:27 — #21
This is a good point, what's the difference between
delay(500) with respect to the user app, power consumption, and reprogrammability OTA?
chrisptd at June 6th, 2014 13:53 — #22
Thanks for pointing out the delays in the Acceleration examples. Those have been changed to use Been.sleep instead.
Delay does not allow the Bean to completely sleep. The Arduino will stay awake and will drain your battery much quicker. Bean.sleep() will allow the Arduino to sleep, reducing your overall power consumption by a great margin. I recommend using Bean.sleep() in place of Bean.delay(), unless you need to delay less than 5ms.
Regarding the issues people are seeing when looping through lots of serial.write commands--the Bean can keep up fairly well, but needs a chance to catch up on the BLE end. Sending a large amount of serial data will tie up your resources quickly, as the UART communication to the LBM313 communicates faster than BLE can send data out. If all of the allotted BLE buffers are constantly full, communication from the client can be difficult. We're writing a primer for this stuff currently that will give some guidance on how to maintain good throughput safely. We're also looking into ways to make tying up the Bean through serial writes less possible, or not possible at all (throttling UART, etc.). In the meantime it's best to throttle your data a bit in your sketch anyway. I'd definitely place a short delay after every four short (<15 bytes) serial write commands or so, say 5ms or more. Thanks again to @Nonsanity and all that helped those that ran into this issue recover their Bean.
coramvaar at June 13th, 2014 16:40 — #23
In my case the BeanLoader sees the bean but then is stuck at the connecting step... I cannot connect, and so I am stuck forever...
The trick with the jumper wire does not help.
Any ideas, please?
( the program that is loaded has a Bean.sleep(120000) setting at the end of the loop: could that be the problem that the bean is asleep for 2 minutes and wakes only for one led flash of 250msec before going back to sleep again for 2 minutes?)
nonsanity at June 13th, 2014 17:17 — #24
While the wire is grounding the reset pin your program won't be running, so sleeps of any length won't matter just then. But you should be able to connect at that time. Are the battery or RSSI value low? Might be worth swapping in a fresh battery just to be sure that isn't compounding the problem.
coramvaar at June 13th, 2014 17:41 — #25
@Nonsanity : Thanks for your help!
It wasn't the battery. The old one was still as good as the new one... But then I got me a decent wire instead of the paperclip, I closed and re-opened Arduino, and re-saved my project with a shorter name instead of the long one with underscores. I don't know whitch or if any of these actions mattered, but voilà: i got connected again!!!
next page →