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
