Re: [avrdude-dev] Problems with stk500hvsp and some attiny45

[Joerg Wunsch]

As Till Harbaum / Lists wrote:

> on a first glimpse i see one difference in the parameters when
> entering hvsp mode. Avrdude is setting bytes 7 and 8 to 0x00/0x32
> which seems to mean that the reset delay is to be set to 500us (0ms
> + 50*10us). avr studio on the other hand is setting this to
> 0x01/0x00 = 1ms.

> ok, i coudn't wait until tomorrow. In the tiny45 config changing

>     resetdelayms        = 0;
>     resetdelayus        = 50;

> to

>     resetdelayms        = 1;
>     resetdelayus        = 0;

> did the trick and i can successfully program one of the chips that
> didn't work before.

I finally got time to review this.  While it's not quite clear what
this parameter actually means in terms of the timing requirements
specified in the datasheet (they are talking about (20...60) µs before
applying +12 V to /RESET, and about 300 µs before starting serial
communication afterwards), the latest revision of the ATtiny45.xml
file has changed these parameters from 0/50 to 1/0.  As our ATtiny45
HVSP definition has been obtained from the XML files before that, we
were using the obsolete values.

I just changed it to what you reported.  Let's hope there are no
further (silent) changes in the XML here.  This is really hard to
track, as we cannot simply take an XML file, and regenerate a complete
avrdude.conf.in snippet for a device out of it (all the information
about the low-level ISP commands is missing from the XML files).

> Another side note: The us delay byte is multiplied by 10 according
> to the spec. resetdelayus should be set to 500 in the config in
> order to have the value 50 being sent via the setup command. Thus
> avrdude should be dividing resetdelayus by 10 before sending it.

The parameters are simply suppsed to match whatever the XML file
specs, and they are usually passed verbatim to the STK500.  I guess
this scaling by 10 is simply done so the sub-millisecond values can be
made fit into one byte, but we don't want to make our lifes more
complicated by trying to be "intelligent" about this.  As can be seen
above, all these values cannot be meaningfully inferred from the
datasheet anyway, so it's best to keep them 1:1 to the XML files.
Nobody is ever going to fill them in manually.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)