EZ-USB GPIF - very odd issue

I am using a Cypress EZ-USB FX2LP (low power version of the FX2) on a
4-layer PCB that I've designed.  I have created a very simple GPIF
waveform that wiggles a couple of control signals and reads/writes data
via the 16-bit data bus.  I am only implementing the single read and
single write waveforms at this time.

Once I started testing my firmware I noticed that the values on the
data bus (Port B & Port D) were not what I expected.  I confirmed this
with the use of a logic analyzer probing the corresponding pins.  The
control signals being wiggled seem to be fine; only FD[15:0] =
{PD[7:0],  PB[7:0]} were having issues.  I decided to run a test that
simply triggered the single write waveform inside a for loop.  In each
iteration, I wrote the current loop index as the value I wanted to
appear on the GPIF data bus (FD[15:0]).  Using the logic analyzer, I
probed the values showing up on the output port pins; some values were
good and other were bad.

So, if I wrote 0..F to GPIF single write waveform, this is what I was
seeing on the data bus (lower nibble)

0000 (0)
0001 (1)
0000 (0)
0001 (1)
0000 (0)
0001 (1)
0110 (6)
0111 (7)
1000 (8)
1001 (9)
1000 (8)
1001 (9)
1000 (8)
1001 (9)
1110 (E)
1111 (F)

If I wrote 00..FF to GPIF it would have the same pattern as above.  I
took the implementation firmware directly from Cypress's application
note: GPIF Primer, per their recommendation.  I have an FX2 development
board in addition to my own PCB that I designed for this chip.  I ran
the exact same .hex file on the FX2 development board and there were
not problems at all.  When I wrote 0..F, I saw 0..F on the output
ports.

My own two thoughts about what's going on:
1) There may some difference between the FX2 and FX2LP that allows my
firmware code to run on the FX2 but not FX2LP.  Please note, the
Cypress Development Board was an FX2 and NOT an FX2LP.  I did do a lot
of research before choosing this chip over the FX2 and found no
difference that would affect this design that much.
2) My FX2LP might be bad.  This would be kinda random since everything
else has worked without problems.  Although, I design silicon ASIC
microprocessors for a living, so I'm sure there could be a defect on
one part of the die that only affects the surrounding area.

Any thoughts would be greatly appreciated.

Thanks.

H iLarry,

larry.kiss@gmail.com wrote:
> So, if I wrote 0..F to GPIF single write waveform, this is what I was
> seeing on the data bus (lower nibble)
> 
> 0000 (0)
> 0001 (1)
> 0000 (0)
> 0001 (1)
> 0000 (0)
> 0001 (1)
> 0110 (6)
> 0111 (7)
> 1000 (8)
> 1001 (9)
> 1000 (8)
> 1001 (9)
> 1000 (8)
> 1001 (9)
> 1110 (E)
> 1111 (F)

Looks like bit 1 and 2 are shorted.

HTH
Wolfgang

-- 
From-address is Spam trap
Use: wolfgang (dot) mahringer (at) sbg (dot) at

Hi Larry

Check Cypress' app note " Migrating From EZ-USB FX2(TM) to EZ-USB
FX2LP(TM) - AN4078_C"

Regards
Mpho
Emsoft Systems
www.techdigisoft.com



larry.kiss@gmail.com wrote:
> I am using a Cypress EZ-USB FX2LP (low power version of the FX2) on a
> 4-layer PCB that I've designed.  I have created a very simple GPIF
> waveform that wiggles a couple of control signals and reads/writes data
> via the 16-bit data bus.  I am only implementing the single read and
> single write waveforms at this time.
>
> Once I started testing my firmware I noticed that the values on the
> data bus (Port B & Port D) were not what I expected.  I confirmed this
> with the use of a logic analyzer probing the corresponding pins.  The
> control signals being wiggled seem to be fine; only FD[15:0] =
> {PD[7:0],  PB[7:0]} were having issues.  I decided to run a test that
> simply triggered the single write waveform inside a for loop.  In each
> iteration, I wrote the current loop index as the value I wanted to
> appear on the GPIF data bus (FD[15:0]).  Using the logic analyzer, I
> probed the values showing up on the output port pins; some values were
> good and other were bad.
>
> So, if I wrote 0..F to GPIF single write waveform, this is what I was
> seeing on the data bus (lower nibble)
>
> 0000 (0)
> 0001 (1)
> 0000 (0)
> 0001 (1)
> 0000 (0)
> 0001 (1)
> 0110 (6)
> 0111 (7)
> 1000 (8)
> 1001 (9)
> 1000 (8)
> 1001 (9)
> 1000 (8)
> 1001 (9)
> 1110 (E)
> 1111 (F)
>
> If I wrote 00..FF to GPIF it would have the same pattern as above.  I
> took the implementation firmware directly from Cypress's application
> note: GPIF Primer, per their recommendation.  I have an FX2 development
> board in addition to my own PCB that I designed for this chip.  I ran
> the exact same .hex file on the FX2 development board and there were
> not problems at all.  When I wrote 0..F, I saw 0..F on the output
> ports.
>
> My own two thoughts about what's going on:
> 1) There may some difference between the FX2 and FX2LP that allows my
> firmware code to run on the FX2 but not FX2LP.  Please note, the
> Cypress Development Board was an FX2 and NOT an FX2LP.  I did do a lot
> of research before choosing this chip over the FX2 and found no
> difference that would affect this design that much.
> 2) My FX2LP might be bad.  This would be kinda random since everything
> else has worked without problems.  Although, I design silicon ASIC
> microprocessors for a living, so I'm sure there could be a defect on
> one part of the die that only affects the surrounding area.
> 
> Any thoughts would be greatly appreciated.
> 
> Thanks.