avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] attiny10 with ftdi and bitbang


From: Darell Tan
Subject: Re: [avrdude-dev] attiny10 with ftdi and bitbang
Date: Tue, 3 Jul 2012 00:13:18 +0800

Hi Matt,

I just realised that all the pins you mentioned are on the FTDI cable,
so am I right to assume you are using the FTDI cable instead of the
normal FTDI breakout board?

The main reason why the cable is not used is due to its limited number
of output signals. Out of 6 lines, 2 are for power, leaving with 4 for
data - 2 inputs, 2 outputs. For a programmer to work correctly, it
requires 3 outputs: RESET, SCK and MOSI. The line you've tied RESET to
is RX, which is an input pin. Normally, it's not possible for the RX
pin of normal serial ports to be driven as an output, but for the case
of FTDI I'm not sure. Instead, you could probably get away with tying
RESET low.

Out of curiousity, have you tried without the diode, and tying RESET
to GND instead? I have a feeling it's not really the diode but the
RESET line.

--
Regards,
Darell Tan


On Sun, Jul 1, 2012 at 9:14 PM, matthew venn <address@hidden> wrote:
> I finally got it working, but I've no idea how!! If anyone can give me some
> ideas on why this works that would be great.
>
> Here is the output of avrdude:
>
> avrdude: AVR device initialized and ready to accept instructions
> bitbang_cmd_tpi(): [ 72 ] [ 00 ]
> bitbang_cmd_tpi(): [ F3 00 ] [ ]
> bitbang_cmd_tpi(): [ 68 C0 ] [ ]
> bitbang_cmd_tpi(): [ 69 3F ] [ ]
> bitbang_cmd_tpi(): [ 20 ] [ 1E ]
> bitbang_cmd_tpi(): [ 72 ] [ 00 ]
> bitbang_cmd_tpi(): [ F3 00 ] [ ]
> bitbang_cmd_tpi(): [ 68 C1 ] [ ]
> bitbang_cmd_tpi(): [ 69 3F ] [ ]
> bitbang_cmd_tpi(): [ 20 ] [ 90 ]
> bitbang_cmd_tpi(): [ 72 ] [ 00 ]
> bitbang_cmd_tpi(): [ F3 00 ] [ ]
> bitbang_cmd_tpi(): [ 68 C2 ] [ ]
> bitbang_cmd_tpi(): [ 69 3F ] [ ]
> bitbang_cmd_tpi(): [ 20 ] [ 03 ]
> avrdude: Device signature = 0x1e9003
>
> with avrdude command:
>
> ./bin/avrdude -C /etc/avrdude.conf -p t10 -c dasaftdi -P /dev/ttyUSB0 -v -v
> -v -v -q
>
> And definition of dasaftdi:
>
> programmer
>   id    = "dasaftdi";
>   desc  = "tiny10 no reset, sck=!rts mosi=!txd miso=!cts";
>   type  = serbb;
>   sck   = ~7; #green (rts)
>   reset = ~2; #yellow (rx)
>   mosi  = ~3; #orange (tx)
>   miso  = ~8; #brown (cts)
>
> The wiring from ftdi to attiny10 was the key part though:
>
> black (gnd) -> 2 (gnd)
> brown (cts) via a diode -> 1 (data)
> orange (tx) via a 1k resistor -> 1 (data)
> red (+5v) -> 5 (vcc)
> black (gnd) -> 6 (reset)
>
> The diode is important, without the programming fails with the previous
> error of getting stuck in the program enable loop for 64 times.
>
> The most confusing thing for me is that the diode has to allow current to
> flow from the miso to the mosi pin. But MOSI stands for master out slave in,
> so isn't this the wrong way round?
>
> But hooray it's working!!!
>
> Cheers,
> Matt
>
>
>
> On 30 June 2012 14:50, Darell Tan <address@hidden> wrote:
>>
>> Hi Matt,
>>
>> Basically the reset line would only go down once, and will not be
>> released until the programming is done. The 2 other lines are the CLK
>> and DATA. Since the DATA line is only used by one party at a time, if
>> the tiny10 tried to transmit while avrdude was transmitting, it would
>> go into an error state and wait for a break. If you could probe the
>> lines with a logic analyzer, I'd be happy to take a look.
>>
>> This problem of yours is quite a puzzle, especially if both tiny10s
>> responded the same way. If the tiny10 can properly frame the zeroes
>> and respond with the TPIIR correctly, it sounds like some protocol
>> error occurred somewhere in between.
>>
>> Well if you have any further thoughts or do get it to work, I'd like
>> to hear about it.
>>
>> --
>> Regards,
>> Darell Tan
>>
>>
>> On Sat, Jun 30, 2012 at 7:23 PM, matthew venn <address@hidden> wrote:
>> > Dan, thanks for this.
>> >
>> >> If it's stuck in that loop, it's basically calling program_enable,
>> >> which sends CMD_SKEY and expects the NVMEN bit in the TPISR register
>> >> to be set.
>> >
>> >
>> > Yes what I'm seeing is the program enable section (detailed in that
>> > Atmel
>> > pdf) called 64 times before avrdude gives up.
>> >
>> > So am I right in that the tiny10 is responding at some points? It's been
>> > harder than usual to trace because all the comms happens on 1 wire. I'm
>> > wondering if I could use some diodes on mosi and miso so I could scope
>> > before they are merged.
>> >
>> > Someone at the hackspace I'm at (Bristol) has an avrisp mk2 which can do
>> > TPI. So I'll try that. I've had exactly the same thing with another
>> > attiny10
>> > so I think it must be my wiring or the software/pc side of things.
>> >
>> > One really odd thing I noticed about avrdude and the dasa config was
>> > that
>> > when I was testing the outputs of the ftdi cable to check that I was
>> > getting
>> > clock etc, was that if I had
>> >
>> > reset = 7
>> > sck = 3
>> >
>> > that would work (both lines generated pulses), but with
>> >
>> > reset = 3
>> > sck = 7
>> >
>> > only one of them would then generate signals. I've written those from
>> > memory
>> > so I'm not entirely sure which way round they are but it seemed like a
>> > bug
>> > to me at the time and now I'm wondering if there is something similar
>> > with
>> > mosi and miso. Except that the mosi miso link check tests OK...
>> >
>> > Oh well, I'll get there in the end I imagine!
>> > Thanks again,
>> >
>> > Matt
>> >
>> > --
>> > Matthew Venn
>> > mattvenn.net
>
>
>
>
> --
> Matthew Venn
> mattvenn.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]