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]

Submitter:  None
Submitted:  Mon 25 Apr 2016 05:07:28 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  Paul Daniels
Originator Email:  -email is unavailable- Open/Closed:  Open
Release:  None Programmer 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>
Group 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.


example:
   # 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
  0x70


***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
  0x70,0x3b


Regards,
Paul.

Anonymous

 

(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 pldaniels (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by None (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.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-25 joerg_wunsch SummarySingle 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.13-f8d8.
    Corresponding source code