Re: [avr-chat] Re: Slow communication with ATTiny13

[Preston Wilson]

I recently finished a commercial project that used the ATTiny13V operating
with the 128 kHz internal oscillator prescaled down to 16 kHz; I did all of
the initial firmware development on an STK500 with an ATTiny13. I mainly
used avrdude under Windows XP to program the parts, but I also used AVR
Studio on occasion. I put in an ~30 second startup window where the uC ran
at 128 kHz before setting the prescaler, and I had no problems programming
with the low voltage ISP interface during the startup window. No problems =
program and verify both worked.

I did this with 3 ATTiny13's on STK500's and 10 ATTiny13V's on prototype
PCBs.

We used jumpers on the prototype boards to control when MISO, MOSI, and SCK
were tied to the programming header vs the external circuitry on the PCB.

I realize this does not help you solve your problem, but my experience says
that there is not an inherent problem in the ATTiny13[V] as you suggest. I
have the ATTiny13's that I used here and they are rev D639. I don't have any
of the 13V's lying around, so I cannot give you the revision of those parts.

-Preston


"Robert von Knobloch" wrote:

> 
> 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
>>> 
>>>   
>>>     
>> 
>> 
>>   
> 
> 
> 
> _______________________________________________
> AVR-chat mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-chat