avrdude fuse bits are ff? but are they?

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

OK admittedly I am confused with the "programmed bit is '0'" logic, so I need my brain rebooted to grasp the avrdude output below:

<br />
avrdude> d lf<br />
>>> d lf<br />
0000  ff                                                

which I incidentally invoked with 'avrdude -p atmega8 lpt1 -t -c dapa'. And seems to indicate my fuse bits are all FF, are they now programmed or set? ...and how do I un-set them?
What I noticed is that I need to remove power to do a power-on reset for the bits to take effect, is this correct? Am using internal oscillator, 4V supply over ISP (parallel-port).

Conrad Braam - www.softcircuitry.blogspot.com - www.plcsimulator.org
Always start off poorly, that way when you finally figure it out, you can get a few surprise hits in.

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

0xFF means they are all unset.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Quote:

0xFF means they are all unset.

but are they?

Do Read Signature operations to check proper connectivity, as you then know what the "correct" answer is.

Lee

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.

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

> Do Read Signature operations to check proper connectivity

This is autmatically done at first be AVRDUDE. It complains if the
signature raed does not match the signature of the device specified
through the -p option.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Magic, thanks for the quick response.
I am not sure how I managed to "unset" (I hope that is the correct terminology here) them all.
Basically I now have a running application that seems to reboot after about 1 second, and assumed the watchdog is now enabled. :oops: So I want to learn how to restore and mess with fuses and find ways to use the watchdog in future.

Now if I want to set(program) the low and high fuse bytes back to default, I get an error, I typed in something like.

write lf 0 0xE1

(I cannot remember the exact response) Is there a good tutorial that shows how to go about this excercise, I did find an online bit-calculator http://www.engbedded.com/cgi-bin/fc.cgi which tallies with my understanding of my chips' spec-sheet but I cannot seem to toggle them - are they driven using a mask?

I also wonder if I need to invest in a Dragon now.

Conrad Braam - www.softcircuitry.blogspot.com - www.plcsimulator.org
Always start off poorly, that way when you finally figure it out, you can get a few surprise hits in.

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

"write lf 0 0xe1" would be the magic sequence. If this triggers an error,
well, you have to tell /which/ error.

However, the low fuse byte isn't related to the watchdog at all but to the
oscillator selection. You selected an external crystal in the range of
either (3...8) MHz, or > 1 MHz, depending on the state of CKOPT (which is
located in the hfuse). Is there an appropriate crystal connected at all?

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
avrdude> w lf 0 0xe1
>>> w lf 0 0xe1
avrdude (write): error writing 0xe1 at 0x00000, rc=-6
avrdude (write): error writing 0xe1 at 0x00000 cell=0xff

I get the same error "rc=-6" back every time, no matter what I try to write so long as it is not FF, (which tells me the bits are not writeable) is there some detailed docs on the setting of the bits to be found?

However I found my problem,
1. I needed to do a chip-erase, and unplug the programmer, since my I/O are interfering in some way with the ISP, it seems that every time I do a "d lf", I corrupt something, because avrdude seems to actually have lost comms because the device signature reports ffffffff until I unplug everything and then do a full power-on-reset and wait for some magical amount of time.
2. I am going to build a buffered programmer-cable, since the "free" parallel-port cable is proving to have it's limitations when doing advanced stuff.

Lastly, (since I am now sorted) I am documenting what I have done so that next weekend I do not forget it all.
Add this line to the makefile to bump up the internal clock speed

AVRDUDE_WRITE_FLASH = -U lfuse:w:0xC2:m

doing so from the terminal just gives junk if the chip is in my target board.
.. and then be sure to run on 5V, not 4.5V , especially if you have a mega8-PU, and not an 8L.

Conrad Braam - www.softcircuitry.blogspot.com - www.plcsimulator.org
Always start off poorly, that way when you finally figure it out, you can get a few surprise hits in.