Hi all,
Confirmed: the fix works on my LCSoft CY7C68013A breakout board. The
PB0-PB7 pins are no longer being driven after acquision ends, tried the 1K
pull up/down test both with and without the fix (not forgetting to reset in
between to force a firmware reload).
Good catch !!!
2013/6/26 Clemens Novak <[email protected]>
> On 2013-06-24 14:23, Joel Holdsworth wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi Ignacio,
> >
> > Just to update you, uwe_ mentioned on IRC that he might have spotted
> > the cause of the bug. He says he may have time to test it later.
> >
> > Apologies for the rather muted response to your bug via the mailing
> > list. Most discussion happens via the IRC channel.
> >
> > I was an very good bit of detective work on your part.
> >
> > Thanks
> > Joel
> >
> >
> > On 23/06/13 19:28, Ignacio García Pérez wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> I seem to have the same problem... I'm using a "barebone"
> >>> CY7C68013A board without any drivers (i.e. the PBx pins are
> >>> directly connected to the DUT). When one of the PB pins samples a
> >>> "1", this level is output still after sampling.
> >>>
> >>> Actually, I had the issue when I was preparing the ATMEGA32 SPI
> >>> dumps: The SPI and the in-circuit programming pins are the same
> >>> and I wasn't able to use the ATMEL programmer after capturing the
> >>> SPI signals. I thought the SPI signals may have tripped up the
> >>> programmer but seems above mentioned behaviour is the culprit.
> >>>
> >>> I am no CY7C68013A expert but according to the datasheet Port B
> >>> has tri state functionality => So it should be possible to set
> >>> the pins before & after acquisition accordingly, we "only" need
> >>> to find the correct place in the firmware...
> >>>
> >> In fact the default state of the port control register is
> >> tristated. You can easily verify that PB0-PB7 are tristated right
> >> after reset or right after you connect the CY7C68013A to the USB
> >> port. It is *after* the fx2lafw firmware is loaded by sigrok and an
> >> acquisition is run that PB0-PB7 are left configured as output. I
> >> would be surprised if it was not caused by a bug in the fx2lafw
> >> firmware.
> >>
> >> The problem here is that IMO this is a very serious bug because it
> >> is causing an electrical conflict on the PB0-PB7 pins on *every*
> >> CY7C68013A based analyzer out there in which the fx2lafw firmware
> >> is being used, and, most importantly, *it is being unnoticed,*
> >> because the DUT won't be disturbed as long as you have an
> >> intermediate input buffer like almost all logic analyzers have. The
> >> electrical stress will eventually cause failure of one or several
> >> I/O pads.
> >>
> >> Regards.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> Regards - Clemens
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>>
> >>>
> > This SF.net email is sponsored by Windows:
> >>>
> >>> Build for Windows Store.
> >>>
> >>> http://p.sf.net/sfu/windows-dev2dev
> >>> _______________________________________________ sigrok-devel
> >>> mailing list [email protected]
> >>> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
> >>>
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> > This SF.net email is sponsored by Windows:
> >>
> >> Build for Windows Store.
> >>
> >> http://p.sf.net/sfu/windows-dev2dev
> >>
> >>
> >>
> >> _______________________________________________ sigrok-devel
> >> mailing list [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
> >>
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.12 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQEcBAEBAgAGBQJRyDosAAoJEIsWlGmq62IgOa4H/0OB4NkSaPjY8x2pU0X45e7E
> > J99XhbdkIL9GgBuXHvglPhbVlcooJhRJxwytLIm1zuCLPU6kImGNpPFZfeqYyEq5
> > atHybbebmfP8Xcdw/DUoKmqy348jiBEz0oZeEefQh2RmAYTsYAt84b5MuS+d69fz
> > +s4TA/Bbfx+CcT0l1pniTeDsqzhz8EoSxT/GmS6wmYx7WobfBiw0+63iRcIpnXKs
> > DNtrWCnRtIqQMX7VqwZYj1x4ZxOeS0UWn6sic6QZ8GC4iGtYfYCIe8FfHqOzEnY5
> > w+udCvN8EwwPoz7opd8/BYmnjx7Leghl/TzqM7bFoRlbz6tzdv91zU4OL2hlIDw=
> > =KTOu
> > -----END PGP SIGNATURE-----
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > _______________________________________________
> > sigrok-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>
>
> Hi all,
>
> I took a closer look at the datasheet and there is a bit which controls
> whether the GPIF Bus is driven during idle state or tri-stated: IDLEDRV
> (bit 0 in GPIFIDLECS). This bit is set to 1 in gpif-acqusition.c, line
> 57. When setting this bit to 0, the bus is tri-stated and things seem to
> work as expected(?).
>
> Below I attached a git diff... Can anyone please test it?
>
> Regards - Clemens
>
>
> diff --git a/gpif-acquisition.c b/gpif-acquisition.c
> index 5368970..20f4632 100644
> --- a/gpif-acquisition.c
> +++ b/gpif-acquisition.c
> @@ -54,7 +54,8 @@ static void gpif_setup_registers(void)
>
> /* When GPIF is idle, tri-state the data bus. */
> /* Bit 7: DONE, bit 0: IDLEDRV. TODO: Set/clear DONE bit? */
> - GPIFIDLECS = (1 << 0);
> + //GPIFIDLECS = (1 << 0);
> + GPIFIDLECS = 0;//(1 << 0);
>
> /* When GPIF is idle, set CTL0-CTL5 to 0. */
> GPIFIDLECTL = 0;
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> sigrok-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
