Good afternoon, everyone. I'm trying to hook up with some folks who have successfully been using a pair of XBee modules to program an Arduino (Diecimilia, in my case) "over the air". I've started by following ladyada's instructions, but I'm only able to get a successful upload about 1 time in 20 (or less often) for sketches of about 3k in size. The basic arduino->PC (er, iMac) serial communication is working splendidly, but the uploads failing. I've detailed some of the errors on this thread on ladyada's forums, and someone far smarter than I has actually been poking into the XBee config in detail, as well as watching the communication with a scope, but he came up short, as well. This seems so amazingly useful that I can't believe people aren't beating down doors to use it, but I've seen very little discussion of it (aside from Rob Faludi and ladyada's write-ups), and not a whole lot of success, either. If you've tried this setup at all, please post here with your experiences!
For one of my applications I was going to write a Perl script that could update a group of ATmega168s. The Perl script when send a RESET string to the '168. A reset function would be called and the bootloader would start. Then the script would call avrdude to download the new firmware.
If you modify the bootloader you can do a software reset by letting the watchdog
timeout. You can do a hardware reset using one of the Arduino pins and a cap.
The bootloader modifications for software reset are n the “Software
Application” hint at http://tinyurl.com/5lnhtj
I haven’t had a chance to finish this yet. Being able to update a group of devices
to the same firmware seemed like it would be useful.
(* jcl *)
Good to see someone else is thinking about this. :) I'm going to have to digest those pages a little more, John, before I can wrap my head around how the bootloader works, but I kind of figured I'd have to go down this road if I was going to find a workable solution...
The local dorkbot group was working on a game that would have hand-held devices
and beacons. It would be a PITA to have to plug each device in to update firmware.
You don't have to look too close at the bootloader. Since the ATmega168 does not
a software reset function (at least that I have found) you need to change a single
line so that WDT timeout will start the bootloader instead of your application.
The easier way to get a reset is to capacitively couple a output pin to the reset.
When you bring the pin low the '168 resets and the bootloader starts. When
the '168 resets the output pin resets to an input pin.
If I do an RF update script I will post a link. I am working on integrating my ZB1 ('168,
arduino compatible) with an iCreate and a simple RF server using an XBee.
(* jcl *)
Hrm. Ladyada's instructions (linked in my first post) actually details configuring DTR pass-through with the XBee. That's not working for me, unfortunately. I get the rare successful upgrade, but mostly errors like
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
avrdude: failed to write flash memory, rc=-4
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
avrdude: stk500_getsync(): not in sync: resp=0x30
avrdude: stk500_recv(): programmer is not responding
So, if the hardware reset is what should do the trick, that's not sufficient (for me, at least).
I'm up in Nashua; I might have to check out one of the Dorkbot meetings.
The DTR pass-thru should work. What size cap are you using?
Is the cap between the DTR and reset or do you have two caps in series (like
the other reset cap?) Do you have access to an oscilloscope to check the reset line?
dorbot-boston has been MIA for a little while. Post a message on the google group if
you want to get together. I am usually at MIT a couple days a week so I can usually
get together in Cambridge around 6:30-7:00PM.
(* jcl *)
I've tried both 0.1µF and 1.0µF caps, in series between the XBee and the reset pin on the Arduino. I don't have an o'scope, unfortunately. I did, however, put an LED in parallel and saw it go from light to dark when the reset occurred. And the reset does occur, but communication between the bootloader and the Arduino IDE breaks down.
Unfortunately you may need an oscilloscope to check the reset line.
You won't catch an oscillation with the LED. You shouldn't be getting
an oscillation but it would nice to see how clean that line is.
The only other thing I can think of is the version of the bootloader. Are you using
the bootloader version that ladyada recommends for this particular application?
(* jcl *)
Her instructions say to use the "default" bootloader; I re-burned the Diecimila one from the IDE using a USBtinyISP. I haven't tried changing the Atmega chip or wiring a bare chip up to a breadboard for this exercise, yet.
Two caps in series, you say? I could give that a try. I'm looking at the Diecimila schematic and don't see any caps attached to the reset line...
I was asking if you had two caps in series by mistake. Two caps in series wouldn't
give you a clean signal.
I was thinking that it would be an easy mistake to make since there is already a
reset cap going from the FTDI.
(* jcl *)
i spent a few hours yesterday on this and gotten it working 9999x better with a few minor changes
check it out
please post bugs/successes to the ladyada.net forum thread because its tough for me to keep track of multiple forums these days