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 <address@hidden> 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 <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
     > [1]https://lists.nongnu.org/mailman/listinfo/avrdude-dev
     >
     _______________________________________________
     avrdude-dev mailing list
     address@hidden
     [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