AVR: best practice regarding fuse settings

[AndyC_772]

Hi all,

I normally turn to PICs when looking for a small microcontroller for a project, but I now have a project which for various reasons requires an AVR. So today, I've been doing the whole where-does-this-wire-go? thing with AVR Studio and a JTAGICE III.

It took a while before I could get anything to download and run, which had me (metaphorically) banging my head against the wall for half the afternoon. When the target, IDE, compiler and PC interface are all new, it's hard to know what to do when a simple 'hello world' pin wiggler won't even start running, much less actually work. But to cut a long story short...

I started by modifying some example code which set the configuration fuses thus:

Code: [Select]

FUSES = {

.extended = 0xFF,
.high = 0xDC,
.low = 0xC2,
};

... which seemed right, as I defined them using the programming window in AVR Studio.

As a general rule, I like to include all a device's configuration within the source files, rather than having to program them separately - but those of you familiar with the AVR will probably have spotted my bug already.

In my fuse settings, DWEN is not configured to allow debugWire to work. So it doesn't. Or rather, it works just fine right up until the point where the fuses get programmed, and then it doesn't work any more and I get a very unhelpful error message from AVR Studio, which is clearly upset and confused. I was too.

I thought I'd bricked my AVR, as I could neither debug it nor talk to it over SPI. To recover it, I eventually discovered that I had to comment out my fuse settings, then download my code again - which worked, fortunately. This then let me exit the debugger gracefully, which in turn makes DWEN inactive and allows SPI access once more. If I just set the fuses directly using the AVR Studio programming window, and don't set them in the code at all, then it all works fine.

In the PIC world, configuration settings are handled by individual compiler directives - one per setting - and the general advice is to let the IDE handle the one that enables debugging. It gets set when debugging, and cleared for normal operation, with no change to the source code required. It's simply left out of the code and gets handled by the IDE.

I can't figure out how to do this on the AVR, though. It appears that I must either activate DWEN if I want to debug, or deactivate it for production. I guess I could do this with a #ifdef, but that seems untidy.

Am I doing something dumb here?

[dannyf]

Use macros instead of magic numbers.

[Bored@Work]

Don't try to set DWEN as part of normal fuse settings. DWEN is evil. In fact, the whole debugWire enable/disable is evil. Only set DWEN (implicitly) by starting/enabling an interactive debugging session in the IDE. And don't forget to disable debugging when you are done with it as the last action in the debugging session.

debugWire enabled means you have no reset pin. That prevents some methods of programming - all programming methods which require reset, like, for example, the popular ISP programming. And without being able to program you also can't program fuses, i.e. you can't turn DWEN off ... The way to get rid of DWEN is that the debugWire protocol contains a command to turn off DWEN. I.e. when that command is sent via debugWire then debugWire effectively commits suicide and returns the AVR to normal operation.

Atmel is very proud of this fuckup. It fails, for example, if the debugging session crashes, leaving the AVR with DWEN on, but no debugWire session to disable DWEN.

[AndyC_772]

Don't try to set DWEN as part of normal fuse settings.

That's exactly what I want to achieve. I just don't know the proper syntax to set and clear the other fuses as per the requirements of my application, but to leave DWEN under control of the IDE.

[thm_w]

http://www.nongnu.org/avr-libc/user-manual/group__avr__fuse.html

Code: [Select]

    FUSES =
    {
        .low = LFUSE_DEFAULT,
        .high = (FUSE_BOOTSZ0 & FUSE_BOOTSZ1 & FUSE_EESAVE & FUSE_SPIEN & FUSE_JTAGEN),
        .extended = EFUSE_DEFAULT,
    };
Scroll down to fuses section in your appropriate io include file, for example: https://android.googlesource.com/toolchain/avr-libc/+/edcf5bc1c8da8cc4c8b560865d2a54b73c1b51d3/avr-libc-1.7.1/include/avr/iom328p.h

Determine low/high/extended bits your hex values equate to, and add them in.

[dannyf]

Being able to embed fuse settings in the hex file is one of the few things Microchip got right.

Atmel unfortunately got it wrong.

[eneuro]

... which seemed right, as I defined them using the programming window in AVR Studio.

Sometimes fuses calculators are unable to suggest that there are a few another fuses that must be changed to get for example desired BOD level and they have to be modified according to AVR datasheet 

When started write code on AVRs simply used debuging using LED & light sensor connected to scope which started send bits in Morse  code after eg. 10 seconds of normal program execution 
So, I could watch critical variables which were set while microcontroller runs at full speed and no need to set debug fuses.

It is easy also log this data using simple LPT optoisolated interface with photodiode and a few lines of code to postproces Morse code bits on PC and output to text file 
 

[AndyC_772]

http://www.nongnu.org/avr-libc/user-manual/group__avr__fuse.html

Code: [Select]

    FUSES =
    {
        .low = LFUSE_DEFAULT,
        .high = (FUSE_BOOTSZ0 & FUSE_BOOTSZ1 & FUSE_EESAVE & FUSE_SPIEN & FUSE_JTAGEN),
        .extended = EFUSE_DEFAULT,
    };

Thanks for the link. It does, however, seem to confirm that setting fuses is an 'all-or-nothing' thing, so there really is no way to specify the state of all the fuses *except* DWEN. It's a pretty horrible omission to find on day 1 of trying to use a new tool chain IMHO.

debuging using LED & light sensor connected to scope which started send bits in Morse  code after eg. 10 seconds of normal program execution 

Yikes, rather you than me. Fortunately my design has a UART interface, so I can drive debug information out of that and either connect it to a PC or decode it with my scope in real time.

[bingo600]

I tend to look at : http://www.engbedded.com/fusecalc
When i need to define the fuses , and it even has avrdude output (for my linux)

I havent gotten around to "this modern nonsense"    Of embedding fuses in the hexfile

Well engbedded is rather nice

/Bingo

[AndyC_772]

I havent gotten around to "this modern nonsense"    Of embedding fuses in the hexfile

How else do you provide a file to a manufacturer for mass production that includes all the information they need?

[dannyf]

debuging using LED & light sensor connected to scope which started send bits in Morse  code

It can be effective but probably not that efficient. I use blinking leds from time to time to indicate simple conditions.

Otherwise, Uart or lcds are more useful - a lcd interface can be constructed with 2-3 lines (fewer if you can tolerate lower speed).

[Psi]

You can encode two different debug situations on one output really easy but just toggling once for A and twice for B.
It's easy to differentiate between a pulse and a state change on the scope by just looking at the waveform.

[eneuro]

a lcd interface can be constructed with 2-3 lines (fewer if you can tolerate lower speed).

Yep I2C LCD can be used but on AVR DIP8 ATTiny85 in many projects where I2C is not needed if you have HV programmer you can use even disabled RESET pin to send debug data directly to PC of course at much higher speeds than in this video, where Morse code delays were choosen to be able debug this thing just looking at output PWM diode without any additional equipment in realtime environment 

However, I have also this magic light sensor and it is easy connect it to xoscope,  point it close to this debug diode and we can see what is going on inside our AVR without touching it  and using only pocket calculator

[dannyf]

Just put a logic analyzer on the pin, either uart or spi or i2c or whatever you want. Most logic analyzers can decode many of the popular protocols and you don't even need to count the pulses yourself. Much faster and simpler than a coupler + scope.

[TerminalJack505]

If you go with a high pin count (>= 44) AVR then you can ditch debugWire and use JTAG for debugging.

[AndyC_772]

Maybe, but in this case the specific AVR chip is already prescribed for other, non-technical reasons. Given free choice, I'd have used a roughly equivalent PIC and not had this problem.

[thm_w]

Thanks for the link. It does, however, seem to confirm that setting fuses is an 'all-or-nothing' thing, so there really is no way to specify the state of all the fuses *except* DWEN. It's a pretty horrible omission to find on day 1 of trying to use a new tool chain IMHO.

I'm a bit confused here. The FUSES directive should be pre-processor, which is placing these settings into the output file of the project:

The Fuse API allows a user to specify the fuse settings for the specific AVR device they are compiling for. These fuse settings will be placed in a special section in the ELF output file, after linking.

That's exactly what I want to achieve. I just don't know the proper syntax to set and clear the other fuses as per the requirements of my application, but to leave DWEN under control of the IDE.

There is no way to not set a fuse value when writing to the register. As far as I can remember, DWEN fuse was an automatic process where it enables it when starting debugging and disabled when you select "stop debugging".

Maybe there is some bug with priorities of which fuse setting is applied first, no idea.
Anyway, could you just IF out that that section out of your code when compiled for debugging? Or have one fuse config for debug and one for release.

Might give it a try later.

edit: related thread http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=138340

[thm_w]

I didn't have a working debugWire setup, but was able to get the FUSES code working. When you start a debug session it does not program the fuses. Fuses are only programmed if you go to production programming, and check the checkbox for Fuses. So I suspect there is something else preventing your debug session from working.

Is the reset line free of capacitors, pullup if exists is 10k or greater?


side note: EFUSE_DEFAULT was defined as "()" which didn't compile for me and had to add the appropriate macro in.

[eneuro]

I'm a bit confused here. The FUSES directive should be pre-processor, which is placing these settings into the output file of the project:

Just wrote template AVR-GCC with FUSES defined to test this and see where in output hex/binary file they are placed 
Fuses defined in C source code prosmps.c before main after included headers:

...
// Fuses for BOD @ 1MHz
FUSES = {
        .extended = EFUSE,
        .high = HFUSE,
        .low = LFUSE,
};
...

Added my fuses settings to makefile and they are passed during compilation to C source file as defined constants LFUSE, HFUSE, EFUSE:

...
# Fuse compiler flags for BOD @ 1MHz
LFUSE=0x42
HFUSE=0xdc
EFUSE=0xff
CFLAGS += -DLFUSE=$(LFUSE) -DHFUSE=$(HFUSE) -DEFUSE=$(EFUSE)
...

There is make log using avr-gcc under Linux:

$ make
...
Compiling: prosmps.c
avr-gcc -c -mmcu=attiny85 -I.  -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=prosmps.lst  -std=gnu99 -DLFUSE=0x42 -DHFUSE=0xdc -DEFUSE=0xff prosmps.c -o prosmps.o
...
Size after:
prosmps.elf  :
section    size      addr
.text        92         0
.fuse         3   8388704
.stab      1716         0
.stabstr     84         0
Total      1895

Looks good and now we are searching where in output hex/binary file (added target for binary output too to my makefile to get row .bin ).

Now searching for those defined fuses during compilation: -DLFUSE=0x42 -DHFUSE=0xdc -DEFUSE=0xff   . It is easy to find them while this template program with empty main is only 95 bytes long for ATTINY85:

$ cat prosmps.hex
:100000000EC028C027C026C025C024C023C022C0DF
:1000100021C020C01FC01EC01DC01CC01BC0112499
:100020001FBECFE5D2E0DEBFCDBF10E0A0E6B0E05E
:10003000ECE5F0E002C005900D92A036B107D9F7CB
:1000400010E0A3E6B0E001C01D92A336B107E1F7CE
:0C00500002D002C0D5CFFFCFF894FFCF44
:03005C0042DCFF84
:00000001FF

$ cat prosmps.bin |bin2hex
0000000: 0ec0 28c0 27c0 26c0 25c0 24c0 23c0 22c0  ..(.'.&.%.$.#.".
0000010: 21c0 20c0 1fc0 1ec0 1dc0 1cc0 1bc0 1124  !. ............$
0000020: 1fbe cfe5 d2e0 debf cdbf 10e0 a0e6 b0e0  ................
0000030: ece5 f0e0 02c0 0590 0d92 a036 b107 d9f7  ...........6....
0000040: 10e0 a3e6 b0e0 01c0 1d92 a336 b107 e1f7  ...........6....
0000050: 02d0 02c0 d5cf ffcf f894 ffcf 42dc ff    ............B..

It looks like those fuses are last 3 bytes in output program  in this order:  LFUSE HFUSE EFUSE so in this case last 3 bytes in my binary file are:
0x42 0xdc 0xff
Last byte is this 0xFF extended fuse 

I've no idea for the moment howto tell manufacturer to extract those fuses bytes from this output hex or binary file, however it is easy and a few lines of code in C to do for me to generate avrdude Linux command from such binary output file to program device (ATTINY85) and then write those fuses too 

Isn't  it manufacturer dependent how to prepare I guess binary (or maybe ihex) files for production programming?
It looks like this information about fuses is in output file, but who knows how reuse it on production line?

[thm_w]

Just wrote template AVR-GCC with FUSES defined to test this and see where in output hex/binary file they are placed 
...
I've no idea for the moment howto tell manufacturer to extract those fuses bytes from this output hex or binary file, however it is easy and a few lines of code in C to do for me to generate avrdude Linux command from such binary output file to program device (ATTINY85) and then write those fuses too 

Cool

Isn't  it manufacturer dependent how to prepare I guess binary (or maybe ihex) files for production programming?
It looks like this information about fuses is in output file, but who knows how reuse it on production line?

Yes, it seems so, some may include EEPROM data, etc.

There are proprietary command line tools for AVRISP, which is what I would use for production: http://support.atmel.com/bin/customer.exe?=&action=viewKbEntry&id=776
In previous comment I was using the programming window in avr studio 6, and jtagice2, not very production friendly.

[eneuro]

There are proprietary command line tools for AVRISP, which is what I would use for production:

By production I mean send it to manufaturer and let it go and have my PCBs soldered with AVR devices on PCB programmed in  factory 

At home it is easy to automate this and put additional sections in output hex/binary file.

...
char fuse_tag[8]  __attribute__((section (".fuse_tag"))) = "FUSELHE:";
...

I've added a few more sections like .fusel .fuseh .fusee and .fuse at the end to automate this things:

$ cat prosmps.bin |bin2hex
0000000: 0ec0 28c0 27c0 26c0 25c0 24c0 23c0 22c0  ..(.'.&.%.$.#.".
...
0000050: 02d0 02c0 d5cf ffcf f894 ffcf 9019 5645  ..............VE
0000060: 523a 3230 3134 3037 3136 7630 3030 3046  R:20140716v0000F
0000070: 5553 454c 3a42 4655 5345 483a dc46 5553  USEL:BFUSEH:.FUS
0000080: 4545 3aff 4655 5345 4c48 453a 42dc ff    EE:.FUSELHE:B..

It adds a few extra descriptive text bytes to output hex/binary file, but it easy to find them and extract from binary file , so .elf is not needed too

From .elf file it is strightforward:

$ avr-objdump -s -j .ver    prosmps.elf
Contents of section .ver:
 800066 32303134 30373136 76303030 30        20140716v0000

$ avr-objdump -s -j .fusel    prosmps.elf
Contents of section .fusel:
 800079 42

$ avr-objdump -s -j .fuseh    prosmps.elf
Contents of section .fuseh:
 800080 dc

$ avr-objdump -s -j .fusee    prosmps.elf
Contents of section .fusee:
 800087 ff

If you don't need them simply remove choosen sections when creating output hex/binary from compiled .elf with .eeprom section too 

$avr-objcopy  -R .eeprom -R .fuse -R .fuse_tag prosmps.elf -O binary prosmps.bin

I've also removed this fuse description tag  .fuse_tag  and left those well defined sections for indyvidual fuse & version sections .ver .fusel .fuseh .fusee   for my automation tools.

0000050: 02d0 02c0 d5cf ffcf f894 ffcf 9019 5645  ..............VE
0000060: 523a 3230 3134 3037 3136 7630 3030 3046  R:20140716v0000F
0000070: 5553 454c 3a42 4655 5345 483a dc46 5553  USEL:BFUSEH:.FUS
0000080: 4545 3aff                                EE:.

[westfw]

From .elf file it is strightforward

i've seen noise over on avrfreaks that implies that atmel thinks that the .elf is the proper "production" file format.  For actual "production", of course, you provide whatever the manufacturer asks for.  Since I think the ability to include fuse values in the .elf is relatively new,  it wouldn't surprise me if the most common format is a separate .hex file for each fuse value.  (avrdude would support that, I think.  Though I doubt whether many production shops use avrdude.)


Surely someone has some kind of production programmer and can look this up in the manual?

[eneuro]

Since I think the ability to include fuse values in the .elf is relatively new,  it wouldn't surprise me if the most common format is a separate .hex file for each fuse value.

I think it is time to ask PCB manufacturer what they are expect to provide for automated MCUs programming during production

It could be nice when PCB is made and electrical tests are made, to be able to do something even more tricky:
power this PCB up, measure voltage on given MCU pin (eg. AVref with external voltage reference which might slightly differ from unit to unit and resistors used) than find section .avref in my output binary (eg. tag AVREF:) and... overwrite default setting (eg. 3.74V for TL431I with resistors) so this way I can provide something like... binary program template, but when PCB is made additional calibration is made and in this example .avref two bytes long (uint16_t) 374 number (3.74V*100) overwritten with exact measured 369  (3.69V*100) while it is  AVref value on one of those manufactured PCBs.

However, I have no idea if such MCU programming process with additional data passed to output binary program file is even possible at factory for smaller series lets say 100-1000 PCBs during PCB manufacturing and doing electrical  test?

[con-f-use]

Code: [Select]

FUSES = {
        .extended = 0xff,
        .high = 0xdc,
        .low = 0x42,
};
Excuse my ignorance, but what does avrdude do with fuse settings like this in your source code (.hex file when compiled)? Under which circumstances does it set the fuses on your uC, when they were specified like this?

[AndyC_772]

However, I have no idea if such MCU programming process with additional data passed to output binary program file is even possible at factory for smaller series lets say 100-1000 PCBs during PCB manufacturing and doing electrical  test?

Normally, for any kind of volume, I would send out the MCUs to a programming company, who have fully automated equipment to unpack the devices, program them, then re-reel them or load them back into trays. The machines used for this process are basically converted pick & place assembly machines, but instead of loading chips onto PCBs, they're inserted into an array of special ZIF sockets instead.

The chips will come back all identical, of course. If per-chip calibration is needed, I'd be expected to provide a test jig that performed any testing and reprogramming necessary, and would have to pay by the hour for the operator's time. Needless to say this pushes up the cost of the assembly and test process, but if it can be included as part of a wider automated functional test process, then the extra cost isn't too high provided the calibration step is quick.