Problem with TPI and "serbb" mode

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with TPI and "serbb" mode

wayne.holder@gmail.com
I'm trying to use AVRDUDE on macOS 0.14.2 to communicate with an ATTiny10
that's connected an FTDI breakout board like this:

TXD  --[1K]---+
              |   +----------------------+
CTS  ---------+---| TPI DATA (1)   RESET | ------+
GND  -------------| GND              VCC | ---+  |
DTR  -------------| TPI CLK           NC |    |  |
                  +----------------------+    |  |
                                              |  |
VCC  -----------------------------------------+  |
                                                 |
RTS  --------------------------------------------+

Note: adapted from http://irq5.io/2010/07/15/programming-the-attiny10/

and using this as the definition for the programmer:

programmer
  id    = "ftdiprog";
  desc  = "FTDI serial port banging, reset=rts sck=dtr mosi=txd miso=cts";
  type  = "serbb";
  miso  = ~8;
  reset = ~7;
  sck   = ~4;
  mosi  = ~3;
;

Note: passed using the - C + switch in file ftdiprog.conf

But, when I use the following invocation (paths removed for brevity)  to
try and read out the device signature value:

avrdude -v -P /dev/cu.usbserial-A50285BI -C +ftdiprog.conf -c ftdiprog -p
t10 -U signature:r:sig.hex:h

It prints the following error (full, verbose response at end of this
message):

MOSI->MISO 0 failed

and this has me stumped.  Is this a bug, or am I doing something wrong?
Also, is there any more information about how to properly use AVRDUDE and
the TPI protocol?  This information I've found online is either rather
dated, or contradicts or other information I've read.

Thanks in advance for any help offered,

Wayne

--full response--

avrdude: Version 6.3, compiled on Sep 21 2018 at 19:15:33

         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         Copyright (c) 2007-2014 Joerg Wunsch


         System wide configuration file is
"/usr/local/Cellar/avrdude/6.3_1/etc/avrdude.conf"

         User configuration file is "/Users/wholder/.avrduderc"

         User configuration file does not exist or is not a regular file,
skipping

         Additional configuration file is
"/var/folders/mt/7rrh06nw8xj05b0052g526300000gn/T/avr-toolchain/etc/ftdiprog.conf"


         Using Port                    : /dev/cu.usbserial-A50285BI

         Using Programmer              : ftdiprog

         AVR Part                      : ATtiny10

         Chip Erase delay              : 0 us

         PAGEL                         : P00

         BS2                           : P00

         RESET disposition             : dedicated

         RETRY pulse                   : SCK

         serial program mode           : yes

         parallel program mode         : yes

         Timeout                       : 0

         StabDelay                     : 0

         CmdexeDelay                   : 0

         SyncLoops                     : 0

         ByteDelay                     : 0

         PollIndex                     : 0

         PollValue                     : 0x00

         Memory Detail                 :


                                  Block Poll               Page
          Polled

           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages
MinW  MaxW   ReadBack

           ----------- ---- ----- ----- ---- ------ ------ ---- ------
----- ----- ---------

           signature      0     0     0    0 no          3   16      0
0     0 0x00 0x00

           fuse           0     0     4    0 no          1   16      0
0     0 0x00 0x00

           calibration    0     0     0    0 no          1   16      0
0     0 0x00 0x00

           lockbits       0     0     0    0 no          1   16      0
0     0 0x00 0x00

           flash          0     0   128    0 no       1024   16      0
0     0 0x00 0x00


         Programmer Type : SERBB

         Description     : design ftdi adatper, reset=dtr sck=tx mosi=rts
miso=cts


MOSI->MISO 0 failed

avrdude: initialization failed, rc=-1

         Double check connections and try again, or use -F to override

         this check.



avrdude done.  Thank you.
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

Didrik Madheden
That error message means that avrdude tried to sanity check the
connection by sending a 0 and a 1 to "MOSI" and reading it back from
"MISO". This could mean any of the following things:
* The MOSI or MISO connection is broken, incorrect or incorrectly specified.
* The MOSI or MISO connection is shorted to something else.
* The MOSI or MISO connection has incorrect polarity specified. The
FTDI chip can be configured to invert the polarity of signals and
maybe that's what happened.

Quick way to check for the last problem:
Temporarily invert the polarity MISO by removing the ~ used for
inverting the signal.

programmer
  id    = "ftdiprog";
  desc  = "FTDI serial port banging, reset=rts sck=dtr mosi=txd miso=cts";
  type  = "serbb";
  miso  = 8;
  reset = ~7;
  sck   = ~4;
  mosi  = ~3;
;

If you now get:
MOSI->MISO 1 failed (0 instead of 1)
...the advice below does not apply.

If instead you get past the check, avrdude should say "MOSI-MISO link
present". If all goes really well, everything will now work.
Otherwise, try inverting MOSI instead.

programmer
  id    = "ftdiprog";
  desc  = "FTDI serial port banging, reset=rts sck=dtr mosi=txd miso=cts";
  type  = "serbb";
  miso  = ~8;
  reset = ~7;
  sck   = ~4;
  mosi  = 3;
;

Or invert other connections or check for other connection problems.

On Tue, 19 Mar 2019 at 23:14, Wayne Holder <[hidden email]> wrote:

>
> I'm trying to use AVRDUDE on macOS 0.14.2 to communicate with an ATTiny10
> that's connected an FTDI breakout board like this:
>
> TXD  --[1K]---+
>               |   +----------------------+
> CTS  ---------+---| TPI DATA (1)   RESET | ------+
> GND  -------------| GND              VCC | ---+  |
> DTR  -------------| TPI CLK           NC |    |  |
>                   +----------------------+    |  |
>                                               |  |
> VCC  -----------------------------------------+  |
>                                                  |
> RTS  --------------------------------------------+
>
> Note: adapted from http://irq5.io/2010/07/15/programming-the-attiny10/
>
> and using this as the definition for the programmer:
>
> programmer
>   id    = "ftdiprog";
>   desc  = "FTDI serial port banging, reset=rts sck=dtr mosi=txd miso=cts";
>   type  = "serbb";
>   miso  = ~8;
>   reset = ~7;
>   sck   = ~4;
>   mosi  = ~3;
> ;
>
> Note: passed using the - C + switch in file ftdiprog.conf
>
> But, when I use the following invocation (paths removed for brevity)  to
> try and read out the device signature value:
>
> avrdude -v -P /dev/cu.usbserial-A50285BI -C +ftdiprog.conf -c ftdiprog -p
> t10 -U signature:r:sig.hex:h
>
> It prints the following error (full, verbose response at end of this
> message):
>
> MOSI->MISO 0 failed
>
> and this has me stumped.  Is this a bug, or am I doing something wrong?
> Also, is there any more information about how to properly use AVRDUDE and
> the TPI protocol?  This information I've found online is either rather
> dated, or contradicts or other information I've read.
>
> Thanks in advance for any help offered,
>
> Wayne
>
> --full response--
>
> avrdude: Version 6.3, compiled on Sep 21 2018 at 19:15:33
>
>          Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
>
>          Copyright (c) 2007-2014 Joerg Wunsch
>
>
>          System wide configuration file is
> "/usr/local/Cellar/avrdude/6.3_1/etc/avrdude.conf"
>
>          User configuration file is "/Users/wholder/.avrduderc"
>
>          User configuration file does not exist or is not a regular file,
> skipping
>
>          Additional configuration file is
> "/var/folders/mt/7rrh06nw8xj05b0052g526300000gn/T/avr-toolchain/etc/ftdiprog.conf"
>
>
>          Using Port                    : /dev/cu.usbserial-A50285BI
>
>          Using Programmer              : ftdiprog
>
>          AVR Part                      : ATtiny10
>
>          Chip Erase delay              : 0 us
>
>          PAGEL                         : P00
>
>          BS2                           : P00
>
>          RESET disposition             : dedicated
>
>          RETRY pulse                   : SCK
>
>          serial program mode           : yes
>
>          parallel program mode         : yes
>
>          Timeout                       : 0
>
>          StabDelay                     : 0
>
>          CmdexeDelay                   : 0
>
>          SyncLoops                     : 0
>
>          ByteDelay                     : 0
>
>          PollIndex                     : 0
>
>          PollValue                     : 0x00
>
>          Memory Detail                 :
>
>
>                                   Block Poll               Page
>           Polled
>
>            Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages
> MinW  MaxW   ReadBack
>
>            ----------- ---- ----- ----- ---- ------ ------ ---- ------
> ----- ----- ---------
>
>            signature      0     0     0    0 no          3   16      0
> 0     0 0x00 0x00
>
>            fuse           0     0     4    0 no          1   16      0
> 0     0 0x00 0x00
>
>            calibration    0     0     0    0 no          1   16      0
> 0     0 0x00 0x00
>
>            lockbits       0     0     0    0 no          1   16      0
> 0     0 0x00 0x00
>
>            flash          0     0   128    0 no       1024   16      0
> 0     0 0x00 0x00
>
>
>          Programmer Type : SERBB
>
>          Description     : design ftdi adatper, reset=dtr sck=tx mosi=rts
> miso=cts
>
>
> MOSI->MISO 0 failed
>
> avrdude: initialization failed, rc=-1
>
>          Double check connections and try again, or use -F to override
>
>          this check.
>
>
>
> avrdude done.  Thank you.
> _______________________________________________
> avrdude-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev



--
/Didrik

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

Joerg Wunsch
In reply to this post by wayne.holder@gmail.com
As Wayne Holder wrote:

> I'm trying to use AVRDUDE on macOS 0.14.2 to communicate with an ATTiny10
> that's connected an FTDI breakout board like this:

Curious: for an FTDI, why use serbb? It's among the slowest possible
options. Don't you have the possibility to use FTDI's MPSSE? All it
requires is one of the supported chips (see the FTDI website), and
the presence of libftdi (which is opensource) on your system.

Since all the bitbanging is then handled inside the FTDI chip, this
is going to be way faster than serbb which has to complicatedly
transfer full USB packets for each single bit change.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

Hannes Weisbach-2
I don’t believe I’ve ever published my TPI for FTDI MPSSE. So, if no-one else has implemented this(I did not follow avrdude development closely), I believe avrdude can't do MPSSE+TPI.

--
Best regards,
Hannes

> Am 20.03.2019 um 08:31 schrieb Joerg Wunsch <[hidden email]>:
>
> As Wayne Holder wrote:
>
>> I'm trying to use AVRDUDE on macOS 0.14.2 to communicate with an ATTiny10
>> that's connected an FTDI breakout board like this:
>
> Curious: for an FTDI, why use serbb? It's among the slowest possible
> options. Don't you have the possibility to use FTDI's MPSSE? All it
> requires is one of the supported chips (see the FTDI website), and
> the presence of libftdi (which is opensource) on your system.
>
> Since all the bitbanging is then handled inside the FTDI chip, this
> is going to be way faster than serbb which has to complicatedly
> transfer full USB packets for each single bit change.
> --
> cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL
>
> http://www.sax.de/~joerg/
> Never trust an operating system you don't have sources for. ;-)
>
> _______________________________________________
> avrdude-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

David Mosberger
MPSSE is limited to FT2232D, FT2232H, and FT4232H chips though, isn't it?

With the patches in 9327 <https://savannah.nongnu.org/patch/?9327> and 9328
<https://savannah.nongnu.org/patch/?9328>, it's possible to program an
ATtiny10 chip in about 2 seconds on Linux and about 5 seconds on Windows
using pretty much any FTDI chip.

  --david

On Wed, Mar 20, 2019 at 3:09 AM Hannes Weisbach <[hidden email]>
wrote:

> I don’t believe I’ve ever published my TPI for FTDI MPSSE. So, if no-one
> else has implemented this(I did not follow avrdude development closely), I
> believe avrdude can't do MPSSE+TPI.
>
> --
> Best regards,
> Hannes
>
> > Am 20.03.2019 um 08:31 schrieb Joerg Wunsch <[hidden email]>:
> >
> > As Wayne Holder wrote:
> >
> >> I'm trying to use AVRDUDE on macOS 0.14.2 to communicate with an
> ATTiny10
> >> that's connected an FTDI breakout board like this:
> >
> > Curious: for an FTDI, why use serbb? It's among the slowest possible
> > options. Don't you have the possibility to use FTDI's MPSSE? All it
> > requires is one of the supported chips (see the FTDI website), and
> > the presence of libftdi (which is opensource) on your system.
> >
> > Since all the bitbanging is then handled inside the FTDI chip, this
> > is going to be way faster than serbb which has to complicatedly
> > transfer full USB packets for each single bit change.
> > --
> > cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL
> >
> > http://www.sax.de/~joerg/
> > Never trust an operating system you don't have sources for. ;-)
> >
> > _______________________________________________
> > avrdude-dev mailing list
> > [hidden email]
> > https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>
>
> _______________________________________________
> avrdude-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

Hannes Weisbach-2


> Am 20.03.2019 um 16:55 schrieb David Mosberger <[hidden email]>:
>
> MPSSE is limited to FT2232D, FT2232H, and FT4232H chips though, isn't it?

And 232H, 4222H, and 4233H

But, yes.

--
Hannes

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

David Mosberger
OK, thanks for clarifying!  My favorite programming cable
<http://www.tag-connect.com/TC2030-FTDI> comes with an FT232RL, so I don't
think it has MPSSE (and be sure to order the 5V version, otherwise, no
programming luck).

  --david

On Wed, Mar 20, 2019 at 10:08 AM Hannes Weisbach <[hidden email]>
wrote:

>
>
> > Am 20.03.2019 um 16:55 schrieb David Mosberger <[hidden email]>:
> >
> > MPSSE is limited to FT2232D, FT2232H, and FT4232H chips though, isn't it?
>
> And 232H, 4222H, and 4233H
>
> But, yes.
>
> --
> Hannes
>
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

Joerg Wunsch
In reply to this post by David Mosberger


Am 20. März 2019 16:55:36 MEZ schrieb David Mosberger <[hidden email]>:

>With the patches in 9327 <https://savannah.nongnu.org/patch/?9327> and
>9328
><https://savannah.nongnu.org/patch/?9328>, it's possible to program an
>ATtiny10 chip in about 2 seconds on Linux and about 5 seconds on
>Windows
>using pretty much any FTDI chip.

OK.  Well, most TPI chips are quite small anyway, so that's certainly tolerable.

My only concern with these patches is the D2XX driver. First, it is only available for some of  the OSes AVRDUDE runs on.

More importantly, it is closed-source (correct me if I'm wrong), so we are not allowed to include it as long as the project is hosted at the FSF. I'm not sure about the source code itself, but at the very least, I could not provide Windows binaries that require the user to install closed-source software first. (Is linking GPL'ed software against such a library legal at all?, assuming the binary is to be redistributed.)

An I correct the TPI patches itself will also workk without D2XX?
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

David Mosberger
Joerg,


> OK.  Well, most TPI chips are quite small anyway, so that's certainly
> tolerable.
>

Yep.

My only concern with these patches is the D2XX driver. First, it is only
> available for some of  the OSes AVRDUDE runs on.
>
> More importantly, it is closed-source (correct me if I'm wrong), so we are
> not allowed to include it as long as the project is hosted at the FSF. I'm
> not sure about the source code itself, but at the very least, I could not
> provide Windows binaries that require the user to install closed-source
> software first. (Is linking GPL'ed software against such a library legal at
> all?, assuming the binary is to be redistributed.)
>

Yes, D2XX is closed source.  I only added compatiliby since the D2XX was
easier to install (at least for me, who doesn't normally work on Windows).

> An I correct the TPI patches itself will also work without D2XX?
>

That's correct.  You can leave out that patch without any ill effects.
From my original email, it seems performance between libftdi1 and D2XX was
about the same:

*The last patch in this series adds support for the FTDI D2XX driver.  I
didn't see much difference in performance between D2XX
and libftdi1 for Windows, but from what I can see, it's far easier to
install the D2XX driver, so I think this is a useful option to have.*


  --david
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

wayne.holder@gmail.com
I was finally able to get the build to work, so I tried an experiment in
the hopes that it might shed some light on what's going on.  I added a
short loop in bitbang.c just before the code runs the test that checks for
a MOSI-MISO link, as show below:

#if 1
    for (int ii = 0; ii < 4; ii++) {
      pgm->setpin(pgm, PIN_AVR_MOSI, ii & 1);
      int val = pgm->getpin(pgm, PIN_AVR_MISO);
      avrdude_message(MSG_INFO, "MISO = %d\n", val);
    }
#endif
    pgm->setpin(pgm, PIN_AVR_MOSI, 0);
    if (pgm->getpin(pgm, PIN_AVR_MISO) != 0) {
      avrdude_message(MSG_INFO, "MOSI->MISO 0 failed\n");
      return -1;
    }
    pgm->setpin(pgm, PIN_AVR_MOSI, 1);
    if (pgm->getpin(pgm, PIN_AVR_MISO) != 1) {
      avrdude_message(MSG_INFO, "MOSI->MISO 1 failed\n");
      return -1;
    }

Then, I ran this invocation:

./avrdude -v -v -v -P /dev/cu.usbserial-A50285BI -C ./avrdude.conf -C
+./ftdiprog.conf -c ftdiprog -p t10 -U signature:r:./sig.hex:h

4 times and changed whether the MISO and MOSI pins were set inverted in
ftdiprog.conf so different values were set for each test.  The results are
even more baffling than I expected.  The curious part is that in the first
two tests (test 1 and 2) you can see the value read from MISO does change
for the first 2 cycles of the loop.  But, for the next two cycles, it stays
stuck at the value set in the 2nd iteration of the loop.  I also tried
added a delay after setpin() is called and before getpin() is called, but
it made no difference.  So, that rules out my pet theory as to why the
MISO-MOSI link test was failing.

Test 1:
  miso  = 8;
  mosi  = 3;
Result:
MISO = 0  <-- Note change detected
MISO = 1  <--
MISO = 1
MISO = 1
MOSI->MISO 0 failed

Test 2:
  miso  = ~8;
  mosi  = 3;
MISO = 1  <-- Note change detected
MISO = 0  <--
MISO = 0
MISO = 0
MOSI->MISO 1 failed

Test 3:
  miso  = 8;
  mosi  = ~3;
Result:
MISO = 1  <-- No change detected
MISO = 1  <--
MISO = 1
MISO = 1
MOSI->MISO 0 failed

Test 4:
  miso  = ~8;
  mosi  = ~3;
Result:
MISO = 0  <-- No change detected
MISO = 0  <--
MISO = 0
MISO = 0
MOSI->MISO 1 failed

Also, to show the bug picture, I've attached a scope trace showing how the
signals change for Test 1.  The top trace is RESET and the next down is SCK
followed by MISO (CTS) and MOSI (TxD).  The signals are probed directly at
the pins on the FTDO breakout board.  There is a 1K resistor connecting TxD
to pin 1 of the ATTiiny10 and the CTS pin connects directly to pin 1.

Also, as noted before, I've tried using different FTDI adapters as well as
different ATTiny10 chips with the same results.

Wayne

[image: IMG_9049.JPG]

On Thu, Mar 21, 2019 at 3:12 PM David Mosberger <[hidden email]> wrote:

> Joerg,
>
>
> > OK.  Well, most TPI chips are quite small anyway, so that's certainly
> > tolerable.
> >
>
> Yep.
>
> My only concern with these patches is the D2XX driver. First, it is only
> > available for some of  the OSes AVRDUDE runs on.
> >
> > More importantly, it is closed-source (correct me if I'm wrong), so we
> are
> > not allowed to include it as long as the project is hosted at the FSF.
> I'm
> > not sure about the source code itself, but at the very least, I could not
> > provide Windows binaries that require the user to install closed-source
> > software first. (Is linking GPL'ed software against such a library legal
> at
> > all?, assuming the binary is to be redistributed.)
> >
>
> Yes, D2XX is closed source.  I only added compatiliby since the D2XX was
> easier to install (at least for me, who doesn't normally work on Windows).
>
> > An I correct the TPI patches itself will also work without D2XX?
> >
>
> That's correct.  You can leave out that patch without any ill effects.
> From my original email, it seems performance between libftdi1 and D2XX was
> about the same:
>
> *The last patch in this series adds support for the FTDI D2XX driver.  I
> didn't see much difference in performance between D2XX
> and libftdi1 for Windows, but from what I can see, it's far easier to
> install the D2XX driver, so I think this is a useful option to have.*
>
>
>   --david
> _______________________________________________
> avrdude-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

IMG_9049.JPG (201K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

René Liebscher
In reply to this post by wayne.holder@gmail.com
   Hi,
   just an idea, have you tried some really large delays, several
   milliseconds?
   serbb was written for real serial port interfaces?
   Maybe an USB based solution needs here more time to report CTS state
   changes back (especially when the USB solution has some internal buffer
   for data and might handle CTS by itself so that no data can be lost.)
   Rene

   Am 23.03.19, 23:28, Wayne Holder <[hidden email]> schrieb:

     I was finally able to get the build to work, so I tried an
     experiment in
     the hopes that it might shed some light on what`s going on. I added
     a
     short loop in bitbang.c just before the code runs the test that
     checks for
     a MOSI-MISO link, as show below:
     #if 1
     for (int ii = 0; ii < 4; ii++) {
     pgm->setpin(pgm, PIN_AVR_MOSI, ii & 1);
     int val = pgm->getpin(pgm, PIN_AVR_MISO);
     avrdude_message(MSG_INFO, "MISO = %d\n", val);
     }
     #endif
     pgm->setpin(pgm, PIN_AVR_MOSI, 0);
     if (pgm->getpin(pgm, PIN_AVR_MISO) != 0) {
     avrdude_message(MSG_INFO, "MOSI->MISO 0 failed\n");
     return -1;
     }
     pgm->setpin(pgm, PIN_AVR_MOSI, 1);
     if (pgm->getpin(pgm, PIN_AVR_MISO) != 1) {
     avrdude_message(MSG_INFO, "MOSI->MISO 1 failed\n");
     return -1;
     }
     Then, I ran this invocation:
     ./avrdude -v -v -v -P /dev/cu.usbserial-A50285BI -C ./avrdude.conf
     -C
     +./ftdiprog.conf -c ftdiprog -p t10 -U signature:r:./sig.hex:h
     4 times and changed whether the MISO and MOSI pins were set inverted
     in
     ftdiprog.conf so different values were set for each test. The
     results are
     even more baffling than I expected. The curious part is that in the
     first
     two tests (test 1 and 2) you can see the value read from MISO does
     change
     for the first 2 cycles of the loop. But, for the next two cycles, it
     stays
     stuck at the value set in the 2nd iteration of the loop. I also
     tried
     added a delay after setpin() is called and before getpin() is
     called, but
     it made no difference. So, that rules out my pet theory as to why
     the
     MISO-MOSI link test was failing.
     Test 1:
     miso = 8;
     mosi = 3;
     Result:
     MISO = 0 <-- Note change detected
     MISO = 1 <--
     MISO = 1
     MISO = 1
     MOSI->MISO 0 failed
     Test 2:
     miso = ~8;
     mosi = 3;
     MISO = 1 <-- Note change detected
     MISO = 0 <--
     MISO = 0
     MISO = 0
     MOSI->MISO 1 failed
     Test 3:
     miso = 8;
     mosi = ~3;
     Result:
     MISO = 1 <-- No change detected
     MISO = 1 <--
     MISO = 1
     MISO = 1
     MOSI->MISO 0 failed
     Test 4:
     miso = ~8;
     mosi = ~3;
     Result:
     MISO = 0 <-- No change detected
     MISO = 0 <--
     MISO = 0
     MISO = 0
     MOSI->MISO 1 failed
     Also, to show the bug picture, I`ve attached a scope trace showing
     how the
     signals change for Test 1. The top trace is RESET and the next down
     is SCK
     followed by MISO (CTS) and MOSI (TxD). The signals are probed
     directly at
     the pins on the FTDO breakout board. There is a 1K resistor
     connecting TxD
     to pin 1 of the ATTiiny10 and the CTS pin connects directly to pin
     1.
     Also, as noted before, I`ve tried using different FTDI adapters as
     well as
     different ATTiny10 chips with the same results.
     Wayne
     [image: IMG_9049.JPG]
     On Thu, Mar 21, 2019 at 3:12 PM David Mosberger <[hidden email]>
     wrote:
     > Joerg,
     >
     >
     > > OK. Well, most TPI chips are quite small anyway, so that`s
     certainly
     > > tolerable.
     > >
     >
     > Yep.
     >
     > My only concern with these patches is the D2XX driver. First, it
     is only
     > > available for some of the OSes AVRDUDE runs on.
     > >
     > > More importantly, it is closed-source (correct me if I`m wrong),
     so we
     > are
     > > not allowed to include it as long as the project is hosted at
     the FSF.
     > I`m
     > > not sure about the source code itself, but at the very least, I
     could not
     > > provide Windows binaries that require the user to install
     closed-source
     > > software first. (Is linking GPL`ed software against such a
     library legal
     > at
     > > all?, assuming the binary is to be redistributed.)
     > >
     >
     > Yes, D2XX is closed source. I only added compatiliby since the
     D2XX was
     > easier to install (at least for me, who doesn`t normally work on
     Windows).
     >
     > > An I correct the TPI patches itself will also work without D2XX?
     > >
     >
     > That`s correct. You can leave out that patch without any ill
     effects.
     > From my original email, it seems performance between libftdi1 and
     D2XX was
     > about the same:
     >
     > *The last patch in this series adds support for the FTDI D2XX
     driver. I
     > didn`t see much difference in performance between D2XX
     > and libftdi1 for Windows, but from what I can see, it`s far easier
     to
     > install the D2XX driver, so I think this is a useful option to
     have.*
     >
     >
     > --david
     > _______________________________________________
     > avrdude-dev mailing list
     > [hidden email]
     > [1]https://lists.nongnu.org/mailman/listinfo/avrdude-dev
     >
     _______________________________________________
     avrdude-dev mailing list
     [hidden email]
     [2]https://lists.nongnu.org/mailman/listinfo/avrdude-dev

References

   1. https://lists.nongnu.org/mailman/listinfo/avrdude-dev
   2. https://lists.nongnu.org/mailman/listinfo/avrdude-dev
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode (giving up)

wayne.holder@gmail.com
In reply to this post by wayne.holder@gmail.com
Well, I'm going to throw in the towel on this one.  I've tried just about
everything I can think of to try and diagnose and fix the problem, but
everything has come up short.  Most recently I've tried:

1. Using another input pin, such as DCD, instead of CTS as the MISO pin ---
No change
2. Adding delays up to a full second to wait before reading the MISO pin
--- No change
3. Unsoldering the FTDI FT232R chip and replacing it with one ordered from
Mouser to make sure I wasn't using a counterfeit -- No change
4. Removing old FTDI drivers, or 3rd party drivers that might interfere --
No change

I was really hoping I could get this to work, as I think being able to use
an inexpensive programming option like this would make a nice addition to
my ATTiny10IDE <https://github.com/wholder/ATTiny10IDE> project.  But,
alas, I've already spent much more time on this than it was probably
worth.  However, I'm very grateful for all the suggestions members of this
group have offered to help me investigate this.  Thanks to everyone!

My best guess on what's wrong is that, for some unknown reason, the
serbb_getpin() function in in serbb_posix.c is not working properly on my
system, as this is the level at which things seem to stop working.  Perhaps
this is due to some other factor, such a problem in the version
of macOS (10.14.2 (18C54) "Mojave") I'm using, or some other external
factor.  I'm just not sure.

As a final note, if anyone has managed to use AVRDUDE 6.3 to program an
ATTiny10 using macOS Mojave, I've love to hear from you.  Or, if anyone
wants to try to reproduce my results, please contact me directly by email
and I'll be happy to send you an ATTiny10 soldered onto a breakout board
that you can use to try this.

Wayne

On Tue, Mar 19, 2019 at 2:41 PM Wayne Holder <[hidden email]> wrote:

> I'm trying to use AVRDUDE on macOS 0.14.2 to communicate with an ATTiny10
> that's connected an FTDI breakout board like this:
>
> TXD  --[1K]---+
>               |   +----------------------+
> CTS  ---------+---| TPI DATA (1)   RESET | ------+
> GND  -------------| GND              VCC | ---+  |
> DTR  -------------| TPI CLK           NC |    |  |
>                   +----------------------+    |  |
>                                               |  |
> VCC  -----------------------------------------+  |
>                                                  |
> RTS  --------------------------------------------+
>
> Note: adapted from http://irq5.io/2010/07/15/programming-the-attiny10/
>
> and using this as the definition for the programmer:
>
> programmer
>   id    = "ftdiprog";
>   desc  = "FTDI serial port banging, reset=rts sck=dtr mosi=txd miso=cts";
>   type  = "serbb";
>   miso  = ~8;
>   reset = ~7;
>   sck   = ~4;
>   mosi  = ~3;
> ;
>
> Note: passed using the - C + switch in file ftdiprog.conf
>
> But, when I use the following invocation (paths removed for brevity)  to
> try and read out the device signature value:
>
> avrdude -v -P /dev/cu.usbserial-A50285BI -C +ftdiprog.conf -c ftdiprog -p
> t10 -U signature:r:sig.hex:h
>
> It prints the following error (full, verbose response at end of this
> message):
>
> MOSI->MISO 0 failed
>
> and this has me stumped.  Is this a bug, or am I doing something wrong?
> Also, is there any more information about how to properly use AVRDUDE and
> the TPI protocol?  This information I've found online is either rather
> dated, or contradicts or other information I've read.
>
> Thanks in advance for any help offered,
>
> Wayne
>
> --full response--
>
> avrdude: Version 6.3, compiled on Sep 21 2018 at 19:15:33
>
>          Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
>
>          Copyright (c) 2007-2014 Joerg Wunsch
>
>
>          System wide configuration file is
> "/usr/local/Cellar/avrdude/6.3_1/etc/avrdude.conf"
>
>          User configuration file is "/Users/wholder/.avrduderc"
>
>          User configuration file does not exist or is not a regular file,
> skipping
>
>          Additional configuration file is
> "/var/folders/mt/7rrh06nw8xj05b0052g526300000gn/T/avr-toolchain/etc/ftdiprog.conf"
>
>
>          Using Port                    : /dev/cu.usbserial-A50285BI
>
>          Using Programmer              : ftdiprog
>
>          AVR Part                      : ATtiny10
>
>          Chip Erase delay              : 0 us
>
>          PAGEL                         : P00
>
>          BS2                           : P00
>
>          RESET disposition             : dedicated
>
>          RETRY pulse                   : SCK
>
>          serial program mode           : yes
>
>          parallel program mode         : yes
>
>          Timeout                       : 0
>
>          StabDelay                     : 0
>
>          CmdexeDelay                   : 0
>
>          SyncLoops                     : 0
>
>          ByteDelay                     : 0
>
>          PollIndex                     : 0
>
>          PollValue                     : 0x00
>
>          Memory Detail                 :
>
>
>                                   Block Poll               Page
>             Polled
>
>            Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages
> MinW  MaxW   ReadBack
>
>            ----------- ---- ----- ----- ---- ------ ------ ---- ------
> ----- ----- ---------
>
>            signature      0     0     0    0 no          3   16      0
> 0     0 0x00 0x00
>
>            fuse           0     0     4    0 no          1   16      0
> 0     0 0x00 0x00
>
>            calibration    0     0     0    0 no          1   16      0
> 0     0 0x00 0x00
>
>            lockbits       0     0     0    0 no          1   16      0
> 0     0 0x00 0x00
>
>            flash          0     0   128    0 no       1024   16      0
> 0     0 0x00 0x00
>
>
>          Programmer Type : SERBB
>
>          Description     : design ftdi adatper, reset=dtr sck=tx mosi=rts
> miso=cts
>
>
> MOSI->MISO 0 failed
>
> avrdude: initialization failed, rc=-1
>
>          Double check connections and try again, or use -F to override
>
>          this check.
>
>
>
> avrdude done.  Thank you.
>
>
>
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode (giving up)

David Mosberger
Wayne,

I attached my original email below.  It has a link to a git repository with
my patches applied.  With those patches, you should be able to use any FTDI
serial chip to program via TPI.

Best regards,

  --david

---
David Mosberger <[hidden email]>
Thu, May 4, 2017, 5:24 PM
to avrdude-dev
I just submitted a series of 7 patches for the ft245r.c (ftdi_syncbb)
driver.

The main objective of this patch series was to add TPI support such that
chips like the ATtiny9 etc can be programmed using an FTDI cable (we happen
to use the 5 volt version of the TC2030-FTDI-TTL-232R, but with the right
connector, FTDI cable TTL-232RG-VSW5V can be used).

However, as it stood, just adding TPI support gave an excruciatingly slow
programming speed.  It was bad on Linux and even worse on Windows (taking
well over a minute to program 1KiB of flash!).

With these patches, programming time is down to 2.6 seconds on Linux and
about 5.2 seconds on Windows (on an old laptop running Windows 8).  This
assumes running at max baudrate (-b750000).  The default baudrate is 150000
so that will be considerable slower, but seems to be a safe default.

The last patch in this series adds support for the FTDI D2XX driver.  I
didn't see much difference in performance between D2XX and libftdi1 for
Windows, but from what I can see, it's far easier to install the D2XX
driver, so I think this is a useful option to have.

For convenience, I created a GIT repository that has all the patches I
submitted so far:

https://bitbucket.org/egauge/avrdude


Of course, it'd be better to have the patches merged into mainline, if
that's possible.

Thanks and best regards,

  --david
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problem with TPI and "serbb" mode

wayne.holder@gmail.com
In reply to this post by wayne.holder@gmail.com
I was finally able to make this work, so I wanted to follow up with a quick
post about what I learned to to again thank those that, ever so graciously,
tried to help me.  Basically, the FTDI driver was not loading even though
it appeared to be installed.  And, when the FTDI driver is not loaded, the
CTS, DCD and DSR signals on the FT232R chip behave very oddly.  In effect,
when the FTDI driver is not loaded a change on CTS, DCD or DSR will be
reported, but further changes will not be reported until one of the other 2
pins change.  I'm not sure where this behavior comes from (perhaps a
default driver in macOS), or perhaps from another driver, but when an
FT232R chip is in this mode, the CTS, DCD and DSR inputs are basically
useless.

As for why the FTDI driver was not loading, well, the answer seems to be
the way I was removing and reinstalling the FTDI driver during my tests.
While I was testing, I would try to uninstall the driver by removing it
from /System/Library/Extensions/  (and reboot) to run tests without the
driver installed, and then copy it back into the
 /System/Library/Extensions/ (and reboot) to reinstall it.  Reinstalling in
this fashion does not seem to work.  You must reinstall from scratch using
the FTDI installer.  So, as a result, nearly all of my tests were run with
the FTDI driver is not loaded.  Note: I think this may have something to do
with recent changes in how drivers are loaded in macOS High Sierra and
Mojave.

The best way I found to check on whether the FTDI driver is actually loaded
is to do the following:

1. Have an active FT232R chip connected and ready (needed to make sure the
driver loads)
2. Using terminal, run this command "kextstat | grep FTDI"
3. If the driver is loaded, this command should echo back something like:

    164    0 0xffffff7f850dd000 0x7000     0x7000
com.FTDI.driver.FTDIUSBSerialDriver (2.4.2)
E16D9540-AF63-36AD-94C4-B1164FBD6078 <76 55 6 5 3 1>

Perhaps this will help someone else down the line but, regardless, thanks
again to everyone that put up with my, perhaps, tedious posts and tried to
help me solve this riddle.

Wayne

On Tue, Mar 19, 2019 at 2:41 PM Wayne Holder <[hidden email]> wrote:

> I'm trying to use AVRDUDE on macOS 0.14.2 to communicate with an ATTiny10
> that's connected an FTDI breakout board like this:
>
> TXD  --[1K]---+
>               |   +----------------------+
> CTS  ---------+---| TPI DATA (1)   RESET | ------+
> GND  -------------| GND              VCC | ---+  |
> DTR  -------------| TPI CLK           NC |    |  |
>                   +----------------------+    |  |
>                                               |  |
> VCC  -----------------------------------------+  |
>                                                  |
> RTS  --------------------------------------------+
>
> Note: adapted from http://irq5.io/2010/07/15/programming-the-attiny10/
>
> and using this as the definition for the programmer:
>
> programmer
>   id    = "ftdiprog";
>   desc  = "FTDI serial port banging, reset=rts sck=dtr mosi=txd miso=cts";
>   type  = "serbb";
>   miso  = ~8;
>   reset = ~7;
>   sck   = ~4;
>   mosi  = ~3;
> ;
>
> Note: passed using the - C + switch in file ftdiprog.conf
>
> But, when I use the following invocation (paths removed for brevity)  to
> try and read out the device signature value:
>
> avrdude -v -P /dev/cu.usbserial-A50285BI -C +ftdiprog.conf -c ftdiprog -p
> t10 -U signature:r:sig.hex:h
>
> It prints the following error (full, verbose response at end of this
> message):
>
> MOSI->MISO 0 failed
>
> and this has me stumped.  Is this a bug, or am I doing something wrong?
> Also, is there any more information about how to properly use AVRDUDE and
> the TPI protocol?  This information I've found online is either rather
> dated, or contradicts or other information I've read.
>
> Thanks in advance for any help offered,
>
> Wayne
>
> --full response--
>
> avrdude: Version 6.3, compiled on Sep 21 2018 at 19:15:33
>
>          Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
>
>          Copyright (c) 2007-2014 Joerg Wunsch
>
>
>          System wide configuration file is
> "/usr/local/Cellar/avrdude/6.3_1/etc/avrdude.conf"
>
>          User configuration file is "/Users/wholder/.avrduderc"
>
>          User configuration file does not exist or is not a regular file,
> skipping
>
>          Additional configuration file is
> "/var/folders/mt/7rrh06nw8xj05b0052g526300000gn/T/avr-toolchain/etc/ftdiprog.conf"
>
>
>          Using Port                    : /dev/cu.usbserial-A50285BI
>
>          Using Programmer              : ftdiprog
>
>          AVR Part                      : ATtiny10
>
>          Chip Erase delay              : 0 us
>
>          PAGEL                         : P00
>
>          BS2                           : P00
>
>          RESET disposition             : dedicated
>
>          RETRY pulse                   : SCK
>
>          serial program mode           : yes
>
>          parallel program mode         : yes
>
>          Timeout                       : 0
>
>          StabDelay                     : 0
>
>          CmdexeDelay                   : 0
>
>          SyncLoops                     : 0
>
>          ByteDelay                     : 0
>
>          PollIndex                     : 0
>
>          PollValue                     : 0x00
>
>          Memory Detail                 :
>
>
>                                   Block Poll               Page
>             Polled
>
>            Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages
> MinW  MaxW   ReadBack
>
>            ----------- ---- ----- ----- ---- ------ ------ ---- ------
> ----- ----- ---------
>
>            signature      0     0     0    0 no          3   16      0
> 0     0 0x00 0x00
>
>            fuse           0     0     4    0 no          1   16      0
> 0     0 0x00 0x00
>
>            calibration    0     0     0    0 no          1   16      0
> 0     0 0x00 0x00
>
>            lockbits       0     0     0    0 no          1   16      0
> 0     0 0x00 0x00
>
>            flash          0     0   128    0 no       1024   16      0
> 0     0 0x00 0x00
>
>
>          Programmer Type : SERBB
>
>          Description     : design ftdi adatper, reset=dtr sck=tx mosi=rts
> miso=cts
>
>
> MOSI->MISO 0 failed
>
> avrdude: initialization failed, rc=-1
>
>          Double check connections and try again, or use -F to override
>
>          this check.
>
>
>
> avrdude done.  Thank you.
>
>
>
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev