[avr-chat] Re: Slow communication with ATTiny13

[Robert von Knobloch]

Thanks for your comments Neil,
I am doing this in a pure programmer, there is no hardware to get in the
way and all signals are clean.
I reported one thing wrongly: in fact the AVRStudio (Windows) has
exactly the same problem and cannot be resolved by clock speed changes.
In all cases I have to set the fuses for a 4.8 MHz clock, program the
chip and afterwards set the fuse back to a 128kHz clock. This also
appears to be the case with a USB programmer from Tuxgraphics.
I rather think that the problem may be inherent to the Tiny13.
By the way, my current batch of chips (ATTINY13 20PU DIL-8) runs approx.
25% fast in 128 kHz mode.
Regards,
Robert von Knobloch
> Date: Wed, 19 Sep 2007 23:08:50 +1000
> From: Neil Davey <address@hidden>
> Subject: Re: [avr-chat] Slow communication with ATTiny13
> To: address@hidden
> Hi Robert,
> Depending on what programmer you are using you can possible use the -B flag.
> I use the ATTiny13 in a commercial project running on the 128kHz 
> internal clock (which I've found in reality is more lower than this)
> I had problems with programming speed till I re-organised what pins 
> where connected where in the circuit..
> I had a part of my circuit that was effectively applying a low pass 
> filter to MISO or MOSI, I can't recall...
>
> This may be part of your problem.. are you able to look at SCK, MOSI and 
> MISO or a cro during programming?
>
> Regards
> Neil Davey
>
> address@hidden wrote:
>   
>> Hello list,
>> I am developing a project using an AT Tiny 13 in a fairly
>> current-reduced application, which requires that I use the internal 128
>> kHz clock.
>> When programming (AVRDUDE + STK500 on OpenSUSE10.2), the write cycle is
>> OK, but verify causes a "avrdude: stk500_2_ReceiveMessage(): timeout"
>> error and after the code has eventually been read (takes some seconds) a
>> "avrdude: verification error, first mismatch at byte 0x00ca         0x64
>> != 0x3f" where the location and target hex are seemingly random.
>> A manual inspection of the programmed code (AVRDUDE in terminal mode,
>> read flash [which works without timing out]) shows that the chip was
>> programmed correctly.
>> This behaviour also occurs with AVRStudio4 but can be resolved by
>> setting the fosc down to 1kHz. This does not work under AVRDUDE. Could
>> anyone point me to the place in the source files where I might be able
>> to tune the timeout??
>>
>> Many thanks,
>>
>> Robert von Knobloch
>>
>>
>> _______________________________________________
>> AVR-chat mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/avr-chat
>>
>>   
>>     
>
>
>