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

[Wayne Holder]

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