SparkFun Forums

[IggyB]

A quick howto for people who want to upload sketches to their Arduino/Sanguino via a WiFly. I'll help where I can, but I don't intend to do a Arduino bootloader modification tutorial so this may not be for the neophyte. Besides, the Arduino bootloader is well commented and reasonably obvious.

My hardware configuration:
ATmega644P w/ modified Sanguino bootloader (see below). WiFly GSX connected to AVR. AVR TX line has 10k/10k voltage divider to WiFly (as it is a sensitive 3.3v device), AVR RX NOT upshifted from WiFly. Make sure your AVR receives a logic one @ 3.3v. See respective data sheet.

• Modify bootloader to use higher baud rate. In my case, with external 16Mhz ceramic resonator I was able to achieve very reliable 57600 w/ not so reliable comms @ higher rates. You want your bootloader baud rate to match your application (aka sketch) baud rate so you don't have to reconfigure the WiFly. Compile and upload (FWIW, I use FTDI bit bang to burn bootloaders w/ avrdude +serjtag). Another tip, if your bootloader uses the ADA watchdog fast reset mods, undef them to give yourself more time to start the upload and to accommodate the > 800ms WiFly time to accept a TCP connection. If you can't or don't want to modify and burn a new bootloader, then figure out what baud rate your current bootloader uses and set your sketch and WiFly to that rate. I've seen Arduino/Sanguino bootloaders using 19.2k and 38.4k. This may work though I have not tested it.
• Configure the WiFly. Initially, I placed the force AdHoc pull-up jumper on GPIO 9 (see datasheet). I should state quickly here that the RN-131 datashseet says that when GPIO 9 is pulled up at boot, AdHoc mode will be entered and the WiFly will have an IP address of 169.254.1.1. It entered AdHoc mode, but it had a different IP address. As an aside, my WiFly (bought from SparkFun) seemed to have a configuration set reasonably different than the stated defaults from Roving Network. YMMV. Quickly I found the IP (you can write an IP detector w/ ping and bash in 2 seconds) and was able to configure it thusly (see datasheet for more info):
  • Enter configuration mode '$$$'
  • Set baud rate to match my bootloader (which matched my sketch/App). 'set u b 57600'
  • Set the print level to 0. 'set sys printlvl 0'
  • Disable comms messages. These are the '*HELLO*', '*OPEN*', and '*CLOS*' messages sent to the host UART and socket connections by the WiFly when a network connection is made. They are useless anyway as they often fire 1+ seconds _after_ connections come and go). You need to get rid of these so that the bootloader and avrdude aren't confused by them when they establish a connection.
    Code: Select all

    set comm close 0
    set comm open 0
    set comm remote 0
    

  • Save the default config 'save'
  • Exit configuration mode 'exit', be sure to reset the device to force the configuration reload.
• Test comms. Use whatever technique you currently use to upload sketches to your chip to send up the standard serial 'echo' program (You do have one of these, don't you?). Make sure it uses the same baud rate as your bootloader and the WiFly. Reset your AVR, telnet to the WiFly on appropriate port (default should be 2000). Type stuff, hit enter and it should be echoed back. Note that telnet is a carriage return buffered interface so no data gets sent over the socket until you hit enter. If you don't see your input echoed back, stop and fix the problem because the next step(s) just won't work.
• Upload sketch with avrdude! I was prepared to write a socket interface to avrdude but reading the manual revealed it already existed (hurray!). You utilize this by setting the port to a network socket. The '-P' argument specified the port and the network socket definition is 'net:host:port'. The Arduino/Sanguino bootloader emulates the 'avrisp' programmer type included in avrdude. There is no need to supply the baud rate via '-b' (sockets have no baud) but you will need to supply the '-F' to force upload despite a failed chip ident. reply. So, the upload avrdude command line (for me w/ the ATmega644P) looks like:
  Code: Select all

  avrdude -c avrisp -p m644p -P net:169.254.1.1:2000 -F -U flash:w:mySketch.hex:i
  

  Make sure you hit reset before slapping return on that command. Then sit back and watch your AVR get a sketch uploaded to it over WiFi.

[IggyB]

I've been using this for almost exactly a year without any problems. I hope you have too.

Recently, I decided to try out the optiboot bootloader on some atmega328p chips I had lying around. If you are unfamiliar with optiboot, it is the descendent of and apparent replacement for the arduino bootloader (though heavily modified). It has some nice features like supporting software serial on chips w/ no usart (not applicable to me). In addition, it offers a smaller bootloader foot print which frees up more program space. Not really much of a problem on chips like the 328p and 644p but hey some people have big code.

It also has a higher default baud rate for uploading your sketch. And this is where a lot of problems with optiboot begin. Despite a comment in the optiboot source header that states that the usart is returned to reset configuration, in fact, the avr's usart still has u2x set. This bit in USCRA, IIRC, when set, halves the serial sampling rate and doubles the clock, effectively a last resort to allow the avr to reach baud rates that would otherwise exceed error tolerances. All-in-all, not my favorite approach, but whatever.

So, if you want to use optibtoot as the bootloader w/ a WiFly+avrdude flash, as I laid out in the previous post, you will need to recompile optiboot and comment out the line that sets U2X. While you are in there, be sure to check that the bootloader baud rate is set appropriately, in my case 57600. The optiboot source I pulled from the git repo was using 57600 with U2X which made the final baud rate 115200 so all I really needed to do was disable U2X.

I should say that for reasons I can elaborate on via PM, I don't use the arduino / sanguino core components, opting instead to write my own avr codes or using assembly, but the bootloader still gives me a way to upload the program hex files. If you go down this route too be sure to clear UCRSA before using the serial port on your avr or U2X will still be set from optiboot.

Enjoy!