bugAVR Downloader/UploaDEr - Bugs: bug #35474, Feature request: print fuse values...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #35474: Feature request: print fuse values in safemode output.

Submitter:  Roger Wolff <rewolff>
Submitted:  Wed 08 Feb 2012 11:42:03 AM UTC
   
 
Category:  None Severity:  1 - Wish
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  Roger Wolff
Open/Closed:  Closed Release:  None
Programmer hardware:  Device type: 

Jump to the original submission

Fri 13 Sep 2013 05:24:28 PM UTC, comment #7: 

I followed your initial suggestion to print out the fuse values
in hex as part of the regular "Safemode OK" message.

I added a configuration option

default_safemode = no;

so users who don't want this feature can now turn off safemode
by default, but I kept it enabled normally.  For those who
disable it in their configuration, the -u option reverts its
meaning (i.e. it enables safemode then).

Joerg Wunsch <joerg_wunsch>
Group administrator
Thu 09 Feb 2012 09:36:36 AM UTC, comment #6: 

Sounds like a plan.

Or how about better "informing" the user when things go bad? e.g.:

"It looks as if LFUSE has gone from 0x99 to 0x00, this means something is terribly wrong. Attempting to put it back may make things worse, but if the fuse is really at 0x00, leaving it like this will mean it is difficult to recover your AVR. I don't know what to do. You take a guess... Y/N. ".

(The "no question" and then "Y/N" is intentional. :-) But not suitable for the final verison. :-) )

Roger Wolff <rewolff>
Thu 09 Feb 2012 07:59:37 AM UTC, comment #5: 


> This has nothing to do with "bitbang" programmers,
> but with signal strength and cable length.


In theory, yes.  In practice, I have only seen false warnings
from safemode in the past 5+ years, so the net effect was more
to confuse the users rather than to provide a safety belt.
("Your XX fuse value has been changed from 0x99 to 0x00, change
it back?"  If you say "y", of course, you only get more error
messages because something in that setup was hosed already
before, which made safemode believe it should salvage something.)

Perhaps we should move the default into the config file, so
anyone who really thinks they need it could put a

safemode = yes

into their ~/.avrduderc file.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 08 Feb 2012 11:20:09 PM UTC, comment #4: 

So, the issue is:

If your programming setup has bad signal integrity, safemode will prevent you from accidentally setting the wrong fuses.

This has nothing to do with "bitbang" programmers, but with signal strength and cable length.

Just like program-then-verify I think this is a good default to have. Check that everything has gone OK. Then somewhere deep in the manual, you mention: "When you have confidence in your programmer, target and their interconnection, you may chose to disable safemode with the -XXX option".

(I've verified hundreds of programming sessions before I decided: My programmer, AVR and their interconnect are reliable enough to program correctly every time, I'll skip the verify step).

Roger Wolff <rewolff>
Wed 08 Feb 2012 04:48:15 PM UTC, comment #3: 

The issue with those "al cheapo" selfmade bitbang programmers
wasn't to overclock the ISP in terms of not satisfying the
f_ISP < f_CPU/4 requirement: you'll usually immediately
notice that, as it already fails to read out the signature
at start-up.

Their issue was that the drivers used (often just a simple
LS-TTL output), together with the length of the cables (you
somehow had to route the signals from your computer's printer
port to the desk) were prone to produce `flakey' signals,
which could eventually lead to the controller getting some
signal sequence that didn't really originate from the
programmer, due to signal distortion.  If you hit that really
bad, the sequence might have resulted in the clocking fuses
being modified, so upon leaving the ISP session, your
controller was at risk of being fused for a clock (like an
external crystal) that wasn't actually present, which resulted
in "shooting into your foot", as this disables further ISP
connections.

So the idea of the "safemode" implementation is to verify
the fuse setting just before closing the ISP session, to
give the user a chance of intervening.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 08 Feb 2012 04:20:44 PM UTC, comment #2: 

Just for your information,
I think the "syncbb" programmer could also go too fast for the part, especially if the part runs off a slow clock source.

Why wouldn't all the other programmers be able to clock a part too fast for their clock?

Roger Wolff <rewolff>
Wed 08 Feb 2012 03:45:57 PM UTC, comment #1: 

Well, I've been comtemplating to disable safemode for all
but the simple bitbang programmers.  Actually, it should
have been enabled only for this type of programmers in the
first place, because they were risky of accidentally
mis-programming fuses upon running them at a too high
SPI clock.  Any other programmers are not affected by this
phenomenon, and don't benefit from safemode in any way.

Safemode is already generally disabled for all AVR32, Xmega,
and AVRtiny (ATtiny10 & friends) devices, because it does not
make sense there.

I think you should rather tackle that down by inserting the
required actions into your Makefile, like:


$ avrdude -qq -p m1284p -P usb -c jtag2 -U efuse:r:-:h -U hfuse:r:-:h -U lfuse:r:-:h
0xff
0x98
0x62


I'll keep the bug report open by now, perhaps other users or
developers would like to comment on this as well.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 08 Feb 2012 11:42:03 AM UTC, original submission:  

Feature request:

AVRDUDE just told me:
   avrdude: safemode: Fuses OK

but in fact they were not OK. The fuses were still in their default configuration, I had forgotten to set them correctly.

If AVRDUDE would print:

   avrdude: safemode: Fuses EE HH LL OK

I could have seen that before... (at least I would have been blaming myself for not seeing it. Now I can pretend I couldn't have known.... :-) )  Now it cost me an hour of debugging before it dawned on me why things weren't working...

Roger Wolff <rewolff>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by rewolff (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-13 joerg_wunsch StatusNone Fixed
        Assigned toNone joerg_wunsch
        Open/ClosedOpen Closed
    2012-02-08 joerg_wunsch Severity3 - Normal 1 - Wish

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code