Re: [avrdude-dev] Problem with TPI and "serbb" mode

[Wayne Holder]

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:

1640 0xff7f850dd000 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  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/7rrh06nw8xj05b0052g52630gn/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
>

Re: [avrdude-dev] 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 
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 (-b75).  The default baudrate is 15
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
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: [avrdude-dev] Problem with TPI and "serbb" mode (giving up)

[Wayne Holder]

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  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  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/7rrh06nw8xj05b0052g52630gn/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 :
>

Re: [avrdude-dev] Problem with TPI and "serbb" mode

[René Liebscher]

   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  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 
 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
 

Re: [avrdude-dev] Problem with TPI and "serbb" mode

[Joerg Wunsch]

Am 20. März 2019 16:55:36 MEZ schrieb David Mosberger :

>With the patches in 9327  and
>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
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: [avrdude-dev] Problem with TPI and "serbb" mode

[David Mosberger]

OK, thanks for clarifying!  My favorite programming cable
 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 
wrote:

>
>
> > Am 20.03.2019 um 16:55 schrieb David Mosberger :
> >
> > 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
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: [avrdude-dev] 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  and 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 
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 :
> >
> > 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
> > avrdude-dev@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>
>
> ___
> avrdude-dev mailing list
> avrdude-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>
___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: [avrdude-dev] Problem with TPI and "serbb" mode

[Hannes Weisbach]

> Am 20.03.2019 um 16:55 schrieb David Mosberger :
>
> 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
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: [avrdude-dev] Problem with TPI and "serbb" mode

[Hannes Weisbach]

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 :
> 
> 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
> avrdude-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: [avrdude-dev] Problem with TPI and "serbb" mode

[Joerg Wunsch]

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
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev