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

[matthew venn]

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