Getting started with logic analyzers - MacOS version

[gfoot]

Here's a photo of mine - apologies it's so blurry, I didn't notice that on the phone screen!

VCC and GND pins appear to be correct but RDY0 and RDY1 look like they're swapped. I will try a capture with the clock connected to RDY0 instead of RDY1.

[hoglet]

Looking at this version:

You can just about make out the traces from pins 8/9 to RDY0/RDY1. I'm about 90% sure that RDY0 and RDY1 are labelled incorrectly on the silk screen.

Dave

[hoglet]

George, I think your board also has an incorrect silk screen.

On the FX2 IC, RDY1 is pin 9. But on your board it looks like that is connected to the pin labelled RDY0, (on the inner row). I think that's where you need to connect your external clock.

But do check with a meter first!

Dave

[gfoot]

hoglet wrote:

George, I think your board also has an incorrect silk screen.

On the FX2 IC, RDY1 is pin 9. But on your board it looks like that is connected to the pin labelled RDY0, (on the inner row). I think that's where you need to connect your external clock.

But do check with a meter first!

Me getting meter probes onto thoses pins was barely possible - I don't have very steady hands! But I think I managed and am confident they were swapped.

However, I still don't see any improvement with the capture, with just RDY0 and PA4 connected.

My device also appears with the 04b4:8613 ID regardless of the jumper position, it's possible the EEPROM comes programmed with that anyway.

[hoglet]

gfoot wrote:

However, I still don't see any improvement with the capture, with just RDY0 and PA4 connected.

That's a shame, I felt sure this was the issue.

The problem is, there are too many variables!

Dave

[gfoot]

Is there any chance I broke it by connecting the clock to the wrong pin? I'm also conscious it's a 3.3V device and my signals are 5V. It's seemed happy so far though, regardless.

BTW I did have quite a lot of mileage out of the simple 8-channel device I started out with, which was some sort of Salae Logic clone. It couldn't sample the clock, but it can read 8 bits at 48MHz. I found that the system I was measuring was well-behaved enough that it was possible to identify the discrete clock cycles based on the changes on the data bus. Later I started running the data bus through a D flip-flop clocked at the end of phase 2, which made it very easy to identify the clock boundaries in the data stream, and I wrote a Python script to take this 48MHz 8-bit log and deduce the clock signal to go with it. I think that was pretty good for up to about 10MHz clock speeds, maybe even 16MHz. The thing it had trouble with was data bus samples being taken while the signals are in transition - the Python script required a few steady values on either side of such transitions in order to be confident which data was valid.

[hoglet]

Quote:

Is there any chance I broke it by connecting the clock to the wrong pin? I'm also conscious it's a 3.3V device and my signals are 5V. It's seemed happy so far though, regardless.

I very much doubt it, and it's officially 5V tolerant.

I've just been looking at the EZ-USB datasheet again (it's been a few years since I last looked).

There are various operating modes described.

I ended up using the "Slave FIFO Asynchronous Write", because it allowed the data to be clocked on the falling edge, and it works with the 1MHz/2MHz clock on the Beeb. But I see from the datasheet (page 51) that the maximum clock is ~1/(50ns + 70ns) i.e. about 8MHz.

The "Slave FIFO Synchronous Write" mode (page 50) allows for a much faster clocking (between 5MHz and 48MHz on the IFCLK pin). Although I have no recollection of ever using this mode, it seems I did:
https://stardot.org.uk/forums/viewtopic ... 74#p249774

Code: Select all

fx2pipe -ifclk=xi > data.bin

Without the -a flag, fx2pipe defaults to Slave FIFO synchronous write mode. And the -ifclk option "x" switches the clock source to be the IFCLK pin, and "i" causes it to be inverted so the falling edge used.

So this might be something else to try.

Sorry this is all so complicated!

Dave

[gfoot]

hoglet wrote:

Code: Select all

fx2pipe -ifclk=xi > data.bin

Without the -a flag, fx2pipe defaults to Slave FIFO synchronous write mode. And the -ifclk option "x" switches the clock source to be the IFCLK pin, and "i" causes it to be inverted so the falling edge used.

So this might be something else to try.

Unfortunately no change in behaviour there - I connected GND, and IFCLK to a 16MHz oscillator, but it didn't send any sample data back. I tried with and without PA4 connected to GND.

I also had a look around in case it's worth buying another board of the other kind - they are hard to come by these days except direct from China. I also saw an eBay listing that had photos of both types of board in the same listing, so if there actually is a difference between them, it's hard to see which you're buying.

That said, given that all these pins are just wired straight into the same chip, surely there shouldn't be a difference aside from the pinout/silkscreen errors. Perhaps something in the EEPROM.

Quote:

Sorry this is all so complicated!

It's not your fault!

[Paganini]

I seem to be missing a post from the thread... maybe the forum software is acting up again. But, I will try to supply the same information as George:

Code: Select all

paganini@cutie:~/6502Decoder/fx2pipe/fx2pipe$ ldd ./fx2pipe
	linux-gate.so.1 (0xb7ee8000)
	libusb-0.1.so.4 => /lib/i386-linux-gnu/libusb-0.1.so.4 (0xb7eab000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7d25000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7d07000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7b2b000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7a29000)
	/lib/ld-linux.so.2 (0xb7eea000)

My device always appears to lsusb as:

Code: Select all

Bus 001 Device 009: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

regardless of whether the jumpers are on or off; in fact, I'm not sure what the jumpers are meant to do here. They don't seem to affect the LEDs either.

My board appears to be exactly the same one as George's - here's a picture of it:

Edit: More info; my RDY1 is on the left (outside) row, my RDY0 is on the right (inside) row. RDY1 appears to be connected to pin 8, while RDY0 is connected to pin 9.

[gfoot]

Paganini wrote:

My device always appears to lsusb as:

Code: Select all

Bus 001 Device 009: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

regardless of whether the jumpers are on or off; in fact, I'm not sure what the jumpers are meant to do here. They don't seem to affect the LEDs either.

J1 is in series with the ground for the two LEDs in that corner of the board, one in particular that flashes when you are sampling data - it makes it not light up.

J2 on the other hand... seems to fix the problem! Combined with using the pin labelled RDY0 instead of RDY1, as these are mislabelled on this board. So it was these two things together that were wrong - I'd unfortunately ruled out J2 as a solution a long time ago, and not tried until now having it removed while using RDY1.

So connecting a clock to RDY1, PA4 to ground, and GND to ground, with J2 removed, I can get samples from fx2pipe:

Code: Select all

gfoot@box:~/logicanalyzer/6502Decoder/fx2pipe$ fx2pipe/fx2pipe -a -n=4k > data.bin
Firmware config: 0x12 0xcb 0xe0 0x0d 0x12
IO loop running...
Downloading firmware [builtin]...
Submitting max. 16 URBs to fill pipeline... 1 submitted
IO loop exited                                         fx2pipe: 4096 bytes in 0.000s)

So that's good! This is the asynchronous synchronous mode, which Dave said is limited in clock speed to about 8MHz. The command for the IFCLK mode didn't work for me, even with J2 removed. I'm tempted to check the pin is labelled correctly etc though and go from there.

Great news though, and thanks for mentioning the jumpers again as I'd been overlooking them for a while now!

[Paganini]

gfoot wrote:

J1 is in series with the ground for the two LEDs in that corner of the board, one in particular that flashes when you are sampling data - it makes it not light up.

Interesting. Mine still blinks even with that jumper off. It must have a solder bridge. (It really is a fairly low-quality board).

Quote:

J2 on the other hand... seems to fix the problem! Combined with using the pin labelled RDY0 instead of RDY1, as these are mislabelled on this board. So it was these two things together that were wrong - I'd unfortunately ruled out J2 as a solution a long time ago, and not tried until now having it removed while using RDY1.

Heeey, cool. I was just reading on another site that J2 seems to have something to do with programming the EEPROM. Maybe with J2 shorted the firmware wasn't getting downloaded?

This is no longer necessary, I guess, but I'll go ahead and share: I finally tracked down an Amazon seller who has the original LCSoft mini version of this board for $12: https://www.amazon.com/EZ-USB-FX2LP-CY7 ... 07Z8W5GSR/

[gfoot]

gfoot wrote:

So that's good! This is the asynchronous synchronous mode, which Dave said is limited in clock speed to about 8MHz. The command for the IFCLK mode didn't work for me, even with J2 removed. I'm tempted to check the pin is labelled correctly etc though and go from there.

Ooh, this works for me too now! I noticed in the timing diagram that Dave posted (page 50) that even in synchronous mode, it wants SLWR to be low - that's RDY1, which is labelled RDY0 on our boards. So tying that low and rerunning the --ifclk=xi command caused it to grab some data.

I was able to sample my system running at 16MHz very well. One problem I found was difficulty sampling from an "off" state - for some reason that didn't work well. But I wanted to capture the reset, so I connected the 6502's NRESET line to the FX2LP's PA5 pin - when this is low, it disables capture. Then I can hold the reset button, run the command, wait for it to be ready, then let go of the reset button:

Code: Select all

???? :          : RESET !!       : 9 : A=?? X=?? Y=?? SP=?? N=? V=? D=0 I=1 Z=? C=?
FFC0 : A2 FF    : LDX #FF        : 2 : A=?? X=FF Y=?? SP=?? N=1 V=? D=0 I=1 Z=0 C=?
FFC2 : 9A       : TXS            : 2 : A=?? X=FF Y=?? SP=FF N=1 V=? D=0 I=1 Z=0 C=?
FFC3 : A9 0C    : LDA #0C        : 2 : A=0C X=FF Y=?? SP=FF N=0 V=? D=0 I=1 Z=0 C=?
FFC5 : 8D 60 FF : STA FF60       : 4 : A=0C X=FF Y=?? SP=FF N=0 V=? D=0 I=1 Z=0 C=?
FFC8 : A9 00    : LDA #00        : 2 : A=00 X=FF Y=?? SP=FF N=0 V=? D=0 I=1 Z=1 C=?
FFCA : 85 00    : STA 00         : 3 : A=00 X=FF Y=?? SP=FF N=0 V=? D=0 I=1 Z=1 C=?
FFCC : A9 80    : LDA #80        : 2 : A=80 X=FF Y=?? SP=FF N=1 V=? D=0 I=1 Z=0 C=?
FFCE : 85 01    : STA 01         : 3 : A=80 X=FF Y=?? SP=FF N=1 V=? D=0 I=1 Z=0 C=?
FFD0 : A9 00    : LDA #00        : 2 : A=00 X=FF Y=?? SP=FF N=0 V=? D=0 I=1 Z=1 C=?
FFD2 : 85 02    : STA 02         : 3 : A=00 X=FF Y=?? SP=FF N=0 V=? D=0 I=1 Z=1 C=?
FFD4 : A9 04    : LDA #04        : 2 : A=04 X=FF Y=?? SP=FF N=0 V=? D=0 I=1 Z=0 C=?
FFD6 : 85 03    : STA 03         : 3 : A=04 X=FF Y=?? SP=FF N=0 V=? D=0 I=1 Z=0 C=?
FFD8 : A2 7F    : LDX #7F        : 2 : A=04 X=7F Y=?? SP=FF N=0 V=? D=0 I=1 Z=0 C=?
FFDA : A0 00    : LDY #00        : 2 : A=04 X=7F Y=00 SP=FF N=0 V=? D=0 I=1 Z=1 C=?
FFDC : B1 00    : LDA (00),Y     : 5 : A=64 X=7F Y=00 SP=FF N=0 V=? D=0 I=1 Z=0 C=?

Now I swear this program has black magic in it - I'm going to lose sleep tonight wondering how on earth it's able to detect an interrupt scenario from sampling only the data bus:

Code: Select all

  524314    8001a 0 d0 ? ? ?
  524315    8001b 1 fd ? ? ?
  524316    8001c 2 c8 ? ? ?
0555 : D0 FD    : BNE 0554       : 3 : A=00 X=45 Y=04 SP=FF N=0 V=0 D=0 I=0 Z=0 C=1
  524317    8001d 0 e8 ? ? ?
  524318    8001e 1 d0 ? ? ?
0554 : E8       : INX            : 2 : A=00 X=46 Y=04 SP=FF N=0 V=0 D=0 I=0 Z=0 C=1
  524319    8001f 0 d0 ? ? ?
  524320    80020 1 d0 ? ? ?
  524321    80021 2 05 ? ? ?
  524322    80022 3 55 ? ? ?
  524323    80023 4 21 ? ? ?
  524324    80024 5 3d ? ? ?
  524325    80025 6 04 ? ? ?
0555 :          : INTERRUPT !!   : 7 : A=00 X=46 Y=04 SP=FC N=0 V=0 D=0 I=1 Z=0 C=1
  524326    80026 0 48 ? ? ?
  524327    80027 1 ad ? ? ?
  524328    80028 2 00 ? ? ?
043D : 48       : PHA            : 3 : A=00 X=46 Y=04 SP=FB N=0 V=0 D=0 I=1 Z=0 C=1
  524329    80029 0 ad ? ? ?
  524330    8002a 1 2d ? ? ?
  524331    8002b 2 ff ? ? ?
  524332    8002c 3 c0 ? ? ?
memory modelling failed at   FF2D: expected 7F actual C0
043E : AD 2D FF : LDA FF2D       : 4 : A=C0 X=46 Y=04 SP=FB N=1 V=0 D=0 I=1 Z=0 C=1 prediction failed
  524333    8002d 0 4a ? ? ?
  524334    8002e 1 4a ? ? ?
0441 : 4A       : LSR A          : 2 : A=60 X=46 Y=04 SP=FB N=0 V=0 D=0 I=1 Z=0 C=0

The prediction failure is due to that location being a VIA's IFR register.

It's amazing what can be achieved from sampling so few lines, and it makes the whole thing much easier to use than other options, much easier to plug in when it's needed. There are a few output options that I think could be added, and it still struggles when it doesn't know the machine state (like starting a capture while the system is already running) and in those cases maybe a little human help could be supported - telling it what the program counter is, register values etc if we can figure them out, or even just that a certain branch was not taken (as it seems to assume they're all taken if it's not sure).

I also tried capturing at 25.175MHz, and while this seemed to work when starting from a running system, it didn't work from reset - fx2pipe seemed to get blocked up after receiving only one block. It's possible that the clock signal I'm sending to the FX2LP is not clean enough - it's certainly not symmetric as I stretch it a lot. But then, it didn't mind at 16MHz - so perhaps it's just too fast.

[hoglet]

That's great news that it is all now working

J2 I think connects to bit A0, which sets the EEPROM device address.

So I guess the EEPROM must contain more than just the IDs? That's probaly described somewhere in the datasheet.

gfoot wrote:

Now I swear this program has black magic in it - I'm going to lose sleep tonight wondering how on earth it's able to detect an interrupt scenario from sampling only the data bus

It uses a heuristic based on what's expected to be seen in bus cycles 2, 3 and 4:
https://github.com/hoglet67/6502Decoder ... 502.c#L610

Code: Select all

??? ??? PCH PCL PSW ??? ???

I could tighten this up further, because the data in cycles 0 and 1 should always be equal (the opcode that is interrupted).

So an interrupt would match the sequence:

Code: Select all

OPC OPC PCH PCL PSW ??? ???

If you new the possible vector values, then you could tighten this further.

This does add a fair amount of overhead to decoding each instruction.

I would be interested if you encounter any false positives.

Dave

[gfoot]

hoglet wrote:

That's great news that it is all now working

J2 I think connects to bit A0, which sets the EEPROM device address.

So I guess the EEPROM must contain more than just the IDs? That's probaly described somewhere in the datasheet.

It seems that way - briefly mentioned on page 6:

Quote:

USB Boot Methods
During the power-up sequence, internal logic checks the I 2
C port
for the connection of an EEPROM whose first byte is either 0xC0
or 0xC2. If found, it uses the VID/PID/DID values in the EEPROM
in place of the internally stored values (0xC0), or it boot-loads the
EEPROM contents into internal RAM (0xC2). If no EEPROM is
detected, FX2LP enumerates using internally stored descriptors.
The default ID values for FX2LP are VID/PID/DID (0x04B4,
0x8613, 0xAxxx where xxx = Chip revision) [5]
.

So the EEPROM can either provide just a device ID, or initial content for the internal RAM. I thought fx2pipe would be overwriting that with the custom firmware though.

Quote:

If you new the possible vector values, then you could tighten this further.

A command line option like --vecrst could work - could it also use memory modelling to track the vector value? It may be reliable enough already but it could also check the expected first instruction of the ISR (through memory modelling again).

I wondered something similar about branches when the flags are not known - I tried a 16-bit capture with "sync" and "rnw", which worked fine even at 25MHz, and now it knows whether such branches were taken or not based on "sync". But in many cases I think it could also have been able to tell from whether the content of the extra cycle matched the opcode of the next instruction.

[gfoot]

Paganini wrote:

Heeey, cool. I was just reading on another site that J2 seems to have something to do with programming the EEPROM. Maybe with J2 shorted the firmware wasn't getting downloaded?

Did this work for you in the end?

And for Dave - if this works for Paganini then we should probably update the wiki with the new information, is that something you'd like to do or would you like some help with it?