From: Ignacio G. P. <ig...@gm...> - 2013-06-22 23:52:04
|
Hi all, (fl2lafw 0.1.1) I've been recently using sigrok to acquire some data using an LCSoft CY7C68013A development board coupled with a custom CPLD board. At some point I noticed weird logic levels (i.e. far from 0V and 3.3V) on the PB0-PB7 pins, and I just realized they are being driven as outputs when acquisition ends, apparently with the same logic level they last saw as inputs. I've double checked everything: during acquisition PB0-PB7 can be driven to either logic 0 or 1 with a simple pull-up or pull-down resistor. Once acquisition ends PB0-PB7 are being driven by the CY7C68013A as outputs and cannot be pulled to the opposite logic state with the resistor. Needless to say this situation causes a bus contention if the input signals change after acquisition ends (which they most likely will), and is likely to cause electrical damage to the CY7C68013A PB0-PB7 pins, the logic buffer (if used) or the system under test. Questions: 1- Can someone else confirm the problem with any other CY7C68013A board? (see note). 2- Why is the firmware driving PB0-PB7 as outputs after acquisition ends?. Note: if you are using one of these CY7C68013A based logic analyzers, they usually have a 74HC244 input buffer. In this case when you probe the signals between the 74HC244 and the CY7C68013A during acquisition you should see clean logic levels (i.e. very close to 0V for logic 0 and very close to 3.3V for logic 1). After acquisition if you change the inputs causing an electrical conflict between the 74HC244 outputs and the CY7C68013A PB0-PB7 pins now being driven as outputs, your should see weird voltage values that depend on the exact components your board has. For example in my case driving a logic 1 from the 74HC244 results in about 2V when that pin is connected to a PB pin that was sampling a logic 0 during acquisition and seems to be now driving a logic 0 output. |
From: Clemens N. <cl...@fa...> - 2013-06-23 13:51:53
|
On 2013-06-23 01:51, Ignacio García Pérez wrote: > Hi all, > > (fl2lafw 0.1.1) > > I've been recently using sigrok to acquire some data using an LCSoft CY7C68013A development board coupled with a custom CPLD board. At some point I noticed weird logic levels (i.e. far from 0V and 3.3V) on the PB0-PB7 pins, and I just realized they are being driven as outputs when acquisition ends, apparently with the same logic level they last saw as inputs. > > I've double checked everything: during acquisition PB0-PB7 can be driven to either logic 0 or 1 with a simple pull-up or pull-down resistor. Once acquisition ends PB0-PB7 are being driven by the CY7C68013A as outputs and cannot be pulled to the opposite logic state with the resistor. > > Needless to say this situation causes a bus contention if the input signals change after acquisition ends (which they most likely will), and is likely to cause electrical damage to the CY7C68013A PB0-PB7 pins, the logic buffer (if used) or the system under test. > > Questions: > > 1- Can someone else confirm the problem with any other CY7C68013A board? (see note). > > 2- Why is the firmware driving PB0-PB7 as outputs after acquisition ends?. > > Note: if you are using one of these CY7C68013A based logic analyzers, they usually have a 74HC244 input buffer. In this case when you probe the signals between the 74HC244 and the CY7C68013A during acquisition you should see clean logic levels (i.e. very close to 0V for logic 0 and very close to 3.3V for logic 1). After acquisition if you change the inputs causing an electrical conflict between the 74HC244 outputs and the CY7C68013A PB0-PB7 pins now being driven as outputs, your should see weird voltage values that depend on the exact components your board has. For example in my case driving a logic 1 from the 74HC244 results in about 2V when that pin is connected to a PB pin that was sampling a logic 0 during acquisition and seems to be now driving a logic 0 output. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev [1] > > _______________________________________________ > sigrok-devel mailing list > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel [2] 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... Regards - Clemens Links: ------ [1] http://p.sf.net/sfu/windows-dev2dev [2] https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Ignacio G. P. <ig...@gm...> - 2013-06-23 18:28:31
|
> > > 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 > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > > |
From: Joel H. <jo...@ai...> - 2013-06-24 12:24:43
|
-----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 sig...@li... >> 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 sig...@li... > 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----- |
From: Clemens N. <cl...@fa...> - 2013-06-26 18:11:21
|
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 sig...@li... >>> 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 sig...@li... >> 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 > sig...@li... > 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; |
From: Ignacio G. P. <ig...@gm...> - 2013-06-27 09:31:48
|
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 <cl...@fa...> > 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 sig...@li... > >>> 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 sig...@li... > >> 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 > > sig...@li... > > 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 > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > |
From: Uwe H. <uw...@he...> - 2013-06-27 13:20:19
|
On Wed, Jun 26, 2013 at 08:11:08PM +0200, Clemens Novak wrote: > 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 Yup, exactly. It was just a typo there, the pins were being driven instead of tri-stated (as the comment in the code indicated). Thanks everyone for reporting and testing, I've fixed this in git, will do some tests myself later (haven't had time yet), but since it's already been tested it should all be fine now. Cheers, Uwe. -- http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org |