Editing Flashing bootloaders on AVR (section)

== Okay, we've got all connected, what now? ==

Well, now you can use avrdude to program the target chip. How, you ask?

I guess before moving on, here's a BEWARE: by programming the chip via avrdude and a programmer, you'll most likely erase the bootloader. avrdude performs the whole flash erase operation by default (this includes the bootloader!) before doing any writes. This is possible to disable using <code>-D</code> option, but ... just be warned.

The usual course of action would be to use avrdude to program the bootloader (and the fuses if they're wrong), and then program the actual firmware the usual way, using the freshly burned bootloader. (Note &quot;fuses&quot; in the AVR lingo just mean a couple of special &quot;configuration&quot; bytes that affect the chip's behaviour; they can be only changed using a programmer.)

So, as a first step, just see if the programmer can talk to the chip:

<pre>avrdude -c {programmer} -P {serial-port} -p {chip-name}</pre>
Where {programmer} is your programmer's nickname (get a list of the possibilities with <code>avrdude -c help</code>; ArduinoISP is <code>arduino</code>) and {chip-name} is the chip's nickname (again, get a list with <code>avrdude -c arduino -p help</code>; <code>atmega32u</code> and <code>atmega32a</code> are the common ones). Finally, for the programmers that use serial port (e.g. arduinoISP), {serial-port} is that (usually <code>comX</code> on windows and <code>/dev/ttySTUFF</code> on normal systems).

You also may need to add <code>-b {baud-rate}</code>, just try 19200, 38400, 57600, 115200 for the baud rates, one of them should work.

If there's a problem, you'll definitely notice from the output. If it goes well, it should say <code>Device signature ...</code> and <code>Fuses OK</code>. An error usually means that the communication isn't happening properly.

Now the syntax to read and write the target chip's flash is quite weird. So, as a start, to read the whole flash, use the above <code>avrdude</code> command and append <code>-U flash:r:firmware.hex:i</code> to get a hex file, or <code>-U flash:r:firmware.bin:r</code> to get a binary file (this one is easier to inspect than the hex if needed).

=== What bootloader to write? ===

There's usually quite a few bootloaders that you could use; but this would be for another document. So just briefly - atmega32u4-based keyboards generally seem to use the DFU bootloader, and that one's possible compile yourself either from ATMEL's sources, or from the LUFA library.

For the atmega32a-based keyboards, you should first try to get the one that your PCB came with - and this generally means asking the person who made it for one. They are all based on the same code [https://www.obdev.at/products/vusb/bootloadhid.html bootloadHID], but the point is that keyboard makers seems to do some modifications to it, namely the condition when to enter the bootloader, and maybe add some visual signal that the bootloader is running.

(To fill in some general info on AVR bootloaders, here's how things work: The upper part of the flash memory on AVR chips (&quot;the end&quot;) can contain some bootloader code. When an ATMEL chip powers up or resets, it checks its fuses, and if they say that it should start with a bootloader (rather than normal firmware at the beginning of the flash), it starts executing the code near the end of the flash memory - where the bootloader should reside. Now the bootloader somehow determines whether it should jump back to the &quot;application code&quot; at the beginning of the flash, or whether it should continue running.)

=== About the fuses ===

These should really not require any modifications. Note that it's possible to almost &quot;brick&quot; the chip by setting &quot;wrong&quot; fuses (yeah, it's almost always possible to recover, but it may require more equipment and maybe soldering).

If you are curious about them, the AVR8 chips usually have 3 fuses (called &quot;low&quot;, &quot;high&quot; and &quot;extended&quot;), each of them is a byte. You can find out by running avrdude (with the correct <code>-p</code> and <code>-c</code>); it should say <code>Fuses OK (E:{byte} H:{byte} L:{byte})</code>. These bytes are fuses.

[http://www.engbedded.com/fusecalc/ Here] is a great database of what various bits in the fuse bytes actually stand for. Google.


[[Category:Guides]]