embedded software boot camp

Fuse Blown

Tuesday, October 3rd, 2006 by Nigel Jones

As a professional developer of embedded systems, I use a lot of sophisticated tools and best practices in order to create the best embedded applications I can. Today, however, I ran into an issue which makes a mockery of much of what I (and presumably you) do.

So what is this issue you ask? Well, in case you are unaware, two very popular microprocessor families (PIC & AVR & probably others) require one to configure multiple parameters in their microcontrollers via fuse bits. These parameters typically cover critical hardware parameters, such as oscillator type and frequency, brown out settings, code protection bits and so on. These fuse settings are NOT programmable from within the application and hence are typically outside the programmer’s direct control. Thus a solution based upon devices in these families consists of both the programming image (i.e. the binary representation of your code) and also the fuse bit settings.

Now, this wouldn’t be too bad if there was some way to combine both sets of information in to one master programming file. In fact both Microchip and Atmel allow one to do this within their IDE’s. However, what happens when one needs to have the microprocessors programmed on a high speed production gang programmer? Well, I found out today – and it isn’t pretty.

The procedure is to supply an Intel Hex record file for the application, and to provide the programming house with an email detailing the required fuse settings! So, after using all the sophisticated tools at my disposal to craft a working embedded system, I ultimately have to rely upon the manual transcription of configuration bits in to a programmer to ensure that the end product is actually programmed the way I need it to be.

This is patently absurd! We need an industry standard programming file that allows both the program image and the configuration bits to be defined, independent of the manufacturer, so that we can be confident that devices are programmed the way we want them to be. (Incidentally, checking a first article device is only of limited benefit, since in many cases, we want to set a lock bit that prevents anyone (including oneself) from reading anything about the device).

Does anyone out there have any ideas on how we can get this problem solved?


One Response to “Fuse Blown”

  1. justinx says:

    I know this is an old article. But if you do not know already:


    /* Print .fuse section of ELF file: avr-objdump -s -j .fuse */
    #define FUSE_BITS_LOW 0x62 /* Low fuse bits setting. */
    #define FUSE_BITS_HIGH 0xDC /* High fuse bits setting. */
    #define FUSE_BITS_EXTENDED 0xFF /* Extended fuse bits setting. */

    /* Print .lock section of ELF file: avr-objdump -s -j .lock */
    #define LOCK_BITS 0xFC /* Lock bits setting. LB Mode 3: Further programming and verification disabled. */

    /* Place fuses in a special section (.fuse) in the .ELF output file. */
    const FUSES = {
    FUSE_BITS_LOW, /* .low */
    FUSE_BITS_HIGH, /* .high */
    FUSE_BITS_EXTENDED, /* .extended */

    /* Place lockbits in a special section (.lock) in the .ELF output file. */

    int main(void)
    uint8_t fuseBitsLow;
    uint8_t fuseBitsHigh;
    uint8_t fuseBitsExtended;
    uint8_t lockBitss;

    /* Read lock bits and fuse bits. */
    fuseBitsLow = boot_lock_fuse_bits_get(GET_LOW_FUSE_BITS);
    fuseBitsHigh = boot_lock_fuse_bits_get(GET_HIGH_FUSE_BITS);
    fuseBitsExtended = boot_lock_fuse_bits_get(GET_EXTENDED_FUSE_BITS);
    lockBitss = boot_lock_fuse_bits_get(GET_LOCK_BITS);

    /* Ensure the lock bits and fuse bits are as expected. */
    if ((fuseBitsLow != FUSE_BITS_LOW) || (fuseBitsHigh != FUSE_BITS_HIGH)
    || (fuseBitsExtended != FUSE_BITS_EXTENDED) || (lockBitss != LOCK_BITS)) {
    } else { }


    The desired lock bits and fuse bits values can be read and stored for programming:
    avr-objdump -s -j .fuse main.elf
    avr-objdump -s -j .lock main.elf

    Details can be found at the following link:

Leave a Reply