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

[avrs-admin]

Paul Daniels pldaniels@gmail.com Mon 25 Apr 2016 05:07:28 AM UTC

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.

This issue was migrated from https://savannah.nongnu.org/bugs/?47780

[avrs-admin]

Joerg Wunsch Mon 25 Apr 2016 06:50:00 AM UTC

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.)

[avrs-admin]

Paul L Daniels Mon 25 Apr 2016 07:06:43 AM UTC

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?

[MCUdude]

@dl8dtl has this been fixed or does OP has faulty hardware?

I've tested this with my USBtiny in TPI mode (using a 1k resistor between MISO and MOSI), and I'm able to read and write to the target just fine. I can also print to a file just like OP is doing, and I can't reproduce the issue.

Should we close the issue?

$ ./avrdude -C avrdude.conf -pattiny104 -c usbtiny -Ucalibration:r:-:h

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e900b (probably t104)
avrdude: reading calibration memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file "<stdout>"
0x46

avrdude done.  Thank you.

./avrdude -C avrdude.conf -pattiny104 -c usbtiny -Ucalibration:r:cal:h

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e900b (probably t104)
avrdude: reading calibration memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file "cal"

avrdude done.  Thank you.

$ cat cal
0x46

[dl8dtl]

has this been fixed

Looking at the history, David Mosberger provided TPI support patches for USBtiny back in 2018. The git hash for the change is 2b9108b58ffbbc1