Re: [sigrok-devel] fx2lafw: PB0-PB7 being driven after acquisition ends

[Joel H. <jo...@ai...>]

-----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-----