bugAVR Downloader/UploaDEr - Bugs: bug #47780, Single byte read/dump results in...


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

bug #47780: Single byte read/dump results in zero byte file written [usbtiny]

Submitted by:  None
Submitted on:  Mon 25 Apr 2016 05:07:28 AM UTC  
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: NonePrivacy: Public
Assigned to: NoneOriginator Name: Paul Daniels
Originator Email: -unavailable-Open/Closed: Open
Release: NoneProgrammer hardware: 
Device type: 

Mon 25 Apr 2016 07:06:43 AM UTC, comment #2:

Thanks for the reply Joerg. For reference, since I failed to detail it in my OP, I'm using a patched avrdude 6.3 to provide TPI-bitbashing via the USBtiny-ISP (needs a 1K resistor to tie MOSI on to MISO to create TPIDATA). Checked with the original source and the diff, no modifications done to the avr_mem_hiaddr() function in this case.

Can't imagine too many people will run in to this one.

I appreciate the explanation, thankyou.

Anything further you require me to do?

Paul L Daniels <pldaniels>
Mon 25 Apr 2016 06:50:00 AM UTC, comment #1:

Thanks for the analysis, Paul!

I just tested it with an AVRISPmkII, and there's no problem.
My usbtiny's firmware is obviously too old to handle TPI, so
I cannot test it using it right now.

The routines in avr.c are merely meant to be used as fallback
routines. If there are shortcomings with them, the respective
programmer's implementation would better provide its own
routine. I think that would be the correct solution in this
case (which is apparently what is already happening for the
AVRISPmkII), as it completely avoids the other issues you
described for different workarounds inside avr.c.

(I modified the subject to indicate this as an usbtiny problem.)

Joerg Wunsch <joerg_wunsch>
Project Administrator
Mon 25 Apr 2016 05:07:28 AM UTC, original submission:

When attempting to dump the single OSCCAL/calibration byte from a Tiny10, a zero byte file is written.

Apologies if this is a PEBCAK situation.

# avrdude -p attiny10 -c usbtiny -U calibration:r:cal:h
# ls -la cal

-rw-rw-r-- 0 pld pld 9 Apr 25 14:55 cal

problem source:
In file avr.c, function int avr_mem_hiaddr(AVRMEM * mem), the for() loop terminates prematurely due to memsize being 1, meaning the initial comparison is 0>0 which of course is false.

for (i=mem->size-1; i>0; i--)

***proposed fix #1, handle the corner case directly, add the test before the for() loop.

if ((mem->size == 1) && (mem->buf[0] != 0xff)) return 1;

The problem with this is that it technically violates the word-size return results expected from avr_mem_hiaddr().

# cat cal

***proposed fix #2, change the for() loop comparison to;

for (i=mem->size-1; i>=0; i--)

The problem with this is that it'll return a size of '2', and write 2 bytes to the file, for what is actually a single byte result.

# cat cal




No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by pldaniels (Posted a comment)
  • -unavailable- added by joerg_wunsch (Posted a comment)
  • -unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 25 Apr 2016 06:50:00 AM UTCjoerg_wunschSummarySingle byte read/dump results in zero byte file written=>Single byte read/dump results in zero byte file written [usbtiny]

    Back to the top

    Powered by Savane 3.1-cleanup1