Setting fuses without erasing USB DFU Bootloader

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all,

 

Newb alert. 

 

I'm using an Atmega16u4, so that I can later update field units via USB DFU. I'm able to connect and upload my firmware via FLIP, but I need to also change a couple fuses (CLKDIV8, for one). From what I've read, I need to connect via ISP and perform a full chip erase to be able to change fuses. (I get a "One or more registers does not match" failure.) Can anyone confirm this? 

 

And if I do a full chip erase, I'm pretty darn sure I erase the bootloader too. Ah jeez. 

 

Do I need another step in there? Like load in the LUFA bootloader before loading in my production firmware? Would that work, as long as I don't do another chip erase before final programming? (I'm not sure how overwriting/ protection of LUFA works.) Like so:

  1. Full chip erase via ISP
  2. Load LUFA bootloader via ISP
  3. Load production flash/ fuse .elf via ISP
  4. Future updates possible in field via USB

 

Any help is greatly appreciated,

Jean 

This topic has a solution.
Last Edited: Tue. Jul 10, 2018 - 02:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You do need ISP to change fuses but you shouldn't need a chip erase. But if you have concerns why not read out the DFU image that is in there to start with?
.
Then, if you have any kind of "accident" you can program it back in afterwards
.
BTW if it's got DFU and it's working then surely all the fuses are set right already? I severely doubt that the USB would be working if CLKDIV8 were active. USB only works if the chip is clocked at 8 or 16 MHz

Last Edited: Mon. Jul 9, 2018 - 07:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Speaking of accidents... There she goes! I guess I'll build another tomorrow :)

 

In Studio, it kept giving me the 'one or more registers does not match" failure when I tried to set the fuses before the full erase. I also got some failures of the "expect 0x00 but see 0xFF" variety when I tried to program it without choosing 'erase'.  

 

And, of course, being a weenie, I can't even figure out how to get LUFA into an actual working project in Studio 7.0! 

 

CLKDIV8 is default active. I just confirmed, as a clock out I'm using dropped from 250kHz to 31.25kHz. I've always thought that the DIVCLK8 being default active was an odd choice on some chips sad

Last Edited: Mon. Jul 9, 2018 - 07:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Strange. I built a second board, and a similar accident happened: I programmed the chip via FLIP, ran the firmware, and I get the 1/8 frequency clock that I expect. I hook it up via ISP, to see if I can set the fuses, and... strangeness. Now the firmware still runs, but I can't get the chip ID via ISP, so can't program fuses or FW, and it doesn't show up in Device Manager. I know I didn't erase it this time. Not even close. But it's essentially bricked (or at least useless at 1/8 frequency that I need), even after power is cycled.  

 

Any ideas on what could do that? 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to http://www.engbedded.com/fusecalc/

CLKDIV8 is set as default.  SPIEN, JTAGEN, HWBE and Clock is set for external XTAL.

 

You can change CLKDIV8 at runtime via the CLKPR register

You can read Signature at runtime.

You can ONLY change fuses with an external programmer

You can only clear lock bits with an external programmer (by erasing ALL Flash memory).

 

Quite honestly,  your 16U4 comes from the factory with a DFU bootloader and is ready to go.

If you want to install a different bootloader,   use an external programmer and set the fuses and lock bits.

 

Dig a big hole and bury the programmer.   From now on,  you use the DFU bootloader.

 

Your App can alter CLKPR or JTD bits at runtime.    It is wise to leave JTAGEN enabled.  There is no harm in leaving CLKDIV8 fuse or clearing it.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now I'll go and have to look at the datasheet. To get the 12MHz needed for USB the chip takes 8 or 16 and multiplies by 3 or 6 to get to 48 then divides by 4 to get back to the required 12. I can only assume this all occurs "upstream" of the CKDIV8 then.

Last Edited: Tue. Jul 10, 2018 - 09:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The bootloader will set the clock prescaler to div1. The App sets it to div1 (if it wants)
.
Personally, I would think it would be more straightforward for chips to come out of the factory with div1.
I think that CLKDIV8 is historic i.e. to migrate from a fused RC1M, RC2M, RC4M, RC8M that the first RC chips had e.g. mega16
It was painful having different RC clock calibrations. Simpler to have a single 8M with prescaler i.e. single calibration.
.
Since USB chips come with XTAL fused clock, it would be easier with div1.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the bootloader clears it to /1 I wonder why OP cares if CKDIV8 is set? Within microseconds of power on the CPU will run at full Xtal speed anyway. So it will just be a handful of opcodes until it reaches the CLKPR that run "slow".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A well behaved bootloader will probably start the App with a Watchdog reset.  This will set all the SFRs to default values and set the prescaler according to the CLKDIV8 fuse.

 

Most Apps set CLKPR to the value that they need.    Because they do not trust the CLKDIV8 setting.

 

Yes,   it is a guaranteed source of confusion for AVR newcomers.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, I should have caught that in the clock register. I wasn't even looking for it, since the code is migrating from an ATtiny84A, where the CLKDIV8 could only be changed via fuses. And it makes sense -- during USB bootloader mode, why would the 16MHz xtal get divided by 8?

Thanks a ton! 

 

I'll keep the fuses as they are, and lock away my programmer.

Why connecting to ISP killed my ability to read the device ID and reprogram it... let's assume it's hardware-related, since no one else seems to have had that issue. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your Tiny84 has a CLKDIV8 fuse and a CLKPR register.   It works the same way.

It is only the old mega8/16/32/64/128 that do not have CLKPR.

 

You can clear CLKDIV8 forever as a fuse.

Or simply use CLKPR in every program.

 

Connecting an external programmer generally involves shooting your foot.

The 16U4 comes out of the factory with a working DFU bootloader.    An external programmer can erase it.

 

Some Apps want to run @ 16MHz.   Other Apps want to run @ 1MHz to save power.

In practice it is more effective to save power by running fast for a short time and sleeping for a long time.

Much better than running slowly without sleep.

 

David.

Last Edited: Tue. Jul 10, 2018 - 02:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I think that CLKDIV8 is historic ...

Historic?  I guess.  Don't all AVR8 chips come from the factory running [about] 1MHz?  Doesn't [every?] datasheet have a note about that -- to ensure running slowly enough to stay within specs at the low end of supplyV?  You/we can disagree, but that is the way it is, right? 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.