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 <[EMAIL PROTECTED]> > Subject: Re: [avr-chat] Slow communication with ATTiny13 > To: [email protected] > 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 > > [EMAIL PROTECTED] 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 >> [email protected] >> http://lists.nongnu.org/mailman/listinfo/avr-chat >> >> >> > > >
_______________________________________________ AVR-chat mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-chat
