Getting started with logic analyzers - MacOS version

[hoglet]

gfoot wrote:

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?

I'll have a go at this tomorrow.

Does your system have the lsusb command?

If so, could you run this command in each of the jumper positions?

Code: Select all

lsusb -v -d 04b4:8613

Make sure to unplug/replug each time.

I want to see if there is any difference in the descriptors.

Dave

[gfoot]

hoglet wrote:

Does your system have the lsusb command?

If so, could you run this command in each of the jumper positions?

Code: Select all

lsusb -v -d 04b4:8613

Make sure to unplug/replug each time.

I want to see if there is any difference in the descriptors.

The output was the same in both cases except for this:

Code: Select all

gfoot@box:~$ diff nojumper.txt withjumper.txt
2c2
< Bus 001 Device 098: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit
---
> Bus 001 Device 099: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

I believe that number is just incrementing each time a device is plugged in though - it went up to 100 on the next try. The full log for one of them is attached in case there's something else in there that distinguishes this from the devices you have.

[Paganini]

gfoot wrote:

Did this work for you in the end?

I'm afraid I haven't got to the end yet. I've left this thread go for longer than I wanted - several unrelated things have kept me busy for the last few days. (Today, it was the tree service guys snapping the cable to our house, so we have no internet! I've had to set up my phone as a hotspot to get on right now!)

I did try to get a capture earlier this afternoon with limited success. I did get *different* results - the LA seemed to be getting data - but it was just a whole file of $FB.

Part of the problem is I'm grappling with too many variables at once here; I don't have a stable 6502 system to test it with, because I scavenged parts from Blue April and Peanutbutter-1 to build Blue August. So, maybe the LA was reading fine, and there was just junk on the bus.

Tomorrow I will try to throw together something minimal to test it with.

[hoglet]

gfoot wrote:

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?

I've added a new page to the Wiki:
https://github.com/hoglet67/6502Decoder ... -Analyzers

Let me know if you spot any errors or ommisions.

Dave

[gfoot]

hoglet wrote:

I've added a new page to the Wiki:
https://github.com/hoglet67/6502Decoder ... -Analyzers

Let me know if you spot any errors or ommisions.

Dave

Nice! Some corrections/additions:

Quote:

There is one connector pin that is 3V3 on the LCSoft board, and GND on the Geeetech board. If you are designing an adaptor for the FX2 board, it's best to leave this pin unconnected.

There's at least one more, next to IFCLK, that's GND on LCSoft and VCC on Geeetech - i.e. the other way around.

Quote:

Jumper J2 must be fitted, otherwise captures from fx2pipe will not work.

Other way around - it must not be fitted. I used it instead to bridge from SLWR to GND which was quite convenient!

Quote:

In practice the maxiumum clock speed is limited by the USB-2 transfer rate, and the data width. In 16-bit mode the limit appears to be 20MHz. In 8-bit mode the limit is 40MHz. This value is also likely to depend on the speed of the host.

For me, 16-bit sampling at 25.175MHz seems to work just as well as 8-bit sampling does - i.e. it's fine in general, but fails if I try to capture the reset sequence. The amount it manages to capture varies, but is typically a few hundred thousand samples I think.

Regarding the issue with my reset sequence, my guess is that when my system is running from ROM the extensive clock-stretching is upsetting the FX2, perhaps because the clock has a very skewed duty cycle and very long high periods that may be equivalent to the high periods of a regular 4MHz clock, and that's below the specified 5MHz. This is just a theory, but does create a bit of a quandry as one mode can only go up to about 7MHz and the other can't go below 5MHz, and it might be worth cautioning that clock stretching might bring your IFCLK out of the required range.

I was considering verifying this by rewiring the capture to the source clock that's consistently 25.175MHz, even though the clock is stretched for the CPU, and using a RDY-like signal to tell the logic analyser when clock stretching is occuring - maybe connecting that to PA5, or just capturing it and letting the decoder deal with RDY being low - but I haven't got around to trying that yet. It doesn't seem to mind the clock stretching as much when running from RAM, when it only occurs for the odd cycle or two during I/O operations.

Edit - I just had a quick go at this, and wiring PA4 to an active-high wait signal (the thing that I'm ORing with the clock to stretch it) while connecting IFCLK to the source clock instead of the stretched clock, generates pretty good captures, including during my reset phase, so it does look like the issue I had there is that my stretched clock stays high for too long. There was one mis-sampling during a JSR call which resulted in a prediction failure there and also on the corresponding RTS; and a second prediction failure when reading a 6522 register, which is expected. The capture is attached but probably not very interesting! (Edit 2 - delaying the IFCLK signal a little fixes the prediction failure)

[Paganini]

I think it's working!

I threw together a little test rig this afternoon:

Minimal6502.pdf

(50.73 KiB) Downloaded 133 times

Tidy, innit? I put a NOP testing ROM in.

Code: Select all

paganini@cutie:~/6502Decoder$ fx2pipe -a -n=4k >capture.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)
paganini@cutie:~/6502Decoder$ hd capture.bin
00000000  ea ea ea ea ea ea ea ea  ea ea ea ea ea ea ea ea  |................|
*
00000030  ea ea ea ea ea bd ea bd  ea bd ea bd ea bd ea bd  |................|
00000040  ea bd ea bd ea bd ea bd  ea bd ea bd ea bd ea bd  |................|
*
00000800  ea ff ea fd ea ff ea fd  ea ff ea fd ea ff ea fd  |................|
*
00001000
paganini@cutie:~/6502Decoder$ ./decode6502 -c 65c02 -ahisy --rdy= --phi2=  capture.bin
opcode ea: cycle prediction fail: expected 7 actual 1
EAEA :          : INTERRUPT !!   : 1 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
opcode ea: cycle prediction fail: expected 7 actual 1
EAEA :          : INTERRUPT !!   : 1 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0 prediction failed
.
.
.
(I deleted a lot of these)
.
.
.
EAEA :          : INTERRUPT !!   : 1 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0 prediction failed
opcode ea: cycle prediction fail: expected 7 actual 1
EAEA :          : INTERRUPT !!   : 1 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0 prediction failed
opcode ea: cycle prediction fail: expected 2 actual 1
EAEA : EA       : NOP            : 1 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
opcode ea: cycle prediction fail: expected 2 actual 1
EAEB : EA       : NOP            : 1 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
opcode ea: cycle prediction fail: expected 2 actual 1
EAEC : EA       : NOP            : 1 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
EAED : EA       : NOP            : 1 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
Instruction after rst /= 7 cycles
EAEE : EA       : NOP            : 2 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
EAEF : EA       : NOP            : 2 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
EAF0 : EA       : NOP            : 2 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
EAF1 : EA       : NOP            : 2 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
EAF2 : EA       : NOP            : 2 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
EAF3 : EA       : NOP            : 2 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
EAF4 : EA       : NOP            : 2 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0
EAF5 : EA       : NOP            : 2 : A=?? X=?? Y=?? SP=?? N=1 V=1 D=0 I=1 Z=1 C=0

Not sure what was going on there at first with all the INTERRUPTS! But I did push reset, just like it says, and after reset it's NOPS all the way down.

[Paganini]

hoglet wrote:

Code: Select all

lsusb -v -d 04b4:8613

Make sure to unplug/replug each time.

I want to see if there is any difference in the descriptors.

Mine is the same as George's, in that it always identifies the same way regardless of jumpers. *HOWEVER,* there was one time earlier this week when it identified as "Lakeview Research." I'm not sure what configuration it was in when that happened; but I believe it was when I had grounded some of its pins to try and get it to do a sync(async) capture, or use an external clock source. I don't know which, though!

[Paganini]

The Wiki wrote:

RDY1 (SLWR) is the external clock, which should be less than 7MHz

Interesting. The capture I just posted above was at 8MHz, with Ø2 connected to RDY0 (or RDY1 or whatever) using fx2pipe -a. I haven't tried to go faster than that, but I didn't realize I was already breaking the speed limit!

[gfoot]

Paganini wrote:

I think it's working!

That's great!

Quote:

Code: Select all

paganini@cutie:~/6502Decoder$ fx2pipe -a -n=4k >capture.bin

That's a 16-bit capture - which of the optional control lines did you hook up? I've only ever bothered with SYNC and RWB as extra inputs for the decoder, but actually get great results with just the data bus hooked up, which is a lot easier to do.

Another thing I found useful was wiring RESET to one of the active-high enable pins, rather than to a data sampling pin - I think I used PA5 - as this meant I could hold down the reset button while starting fx2pipe, and it would not capture any samples until the CPU came out of reset - so the number of samples I requested were taken after the reset, not before it.

Quote:

Not sure what was going on there at first with all the INTERRUPTS! But I did push reset, just like it says, and after reset it's NOPS all the way down.

It looks like your data file contains some byte-wide samples first, followed by word samples. So it thought every other $EA was the high byte of the word, containing the control bits - some of which are low here, and maybe one is for the IRQ pin?

I'm sure Dave has seen this before, where it dumps some stale data at the start. Perhaps he remembers what caused it. There is a --skip option to the decoder but I have a feeling it doesn't work with these synchronous captures, only with the async ones. You can use "dd" to cut some bytes off the start though if necessary - or just ignore everything the decoder says until after the reset, like you did.

Paganini wrote:

Mine is the same as George's, in that it always identifies the same way regardless of jumpers. *HOWEVER,* there was one time earlier this week when it identified as "Lakeview Research." I'm not sure what configuration it was in when that happened; but I believe it was when I had grounded some of its pins to try and get it to do a sync(async) capture, or use an external clock source. I don't know which, though!

Interesting, yet kind of awkward that it can depend on so many aspects of how the device is booted up!

Paganini wrote:

The Wiki wrote:

RDY1 (SLWR) is the external clock, which should be less than 7MHz

Interesting. The capture I just posted above was at 8MHz, with Ø2 connected to RDY0 (or RDY1 or whatever) using fx2pipe -a. I haven't tried to go faster than that, but I didn't realize I was already breaking the speed limit!

I think Dave took that from page 51 of the datasheet (https://datasheetspdf.com/pdf-file/6690 ... 7C68013A/1) where it wants the high phase of the SLWR line (your PHI2) to be at least 70ns - for a 50% duty cycle that'd be 7.1MHz.

It could be worth trying the "Slave FIFO Asynchronous Write" mode now though which is fine at 8MHz - you should just need to move your PHI2 to IFCLK, wire the pin it was originally on to GND, and run with "--ifclk=xi" instead of "-a".

[Paganini]

gfoot wrote:

That's a 16-bit capture - which of the optional control lines did you hook up? I've only ever bothered with SYNC and RWB as extra inputs for the decoder, but actually get great results with just the data bus hooked up, which is a lot easier to do.

For "-s" mode capture I hooked up RESET\, Ø2, R/W\ and SYNC. I have RDY tied high with a resistor, so I left it out. For "-a" mode I moved Ø2 over to RDY0 and RESET\ over to A5 (like you suggested).

Quote:

Another thing I found useful was wiring RESET to one of the active-high enable pins, rather than to a data sampling pin - I think I used PA5 - as this meant I could hold down the reset button while starting fx2pipe, and it would not capture any samples until the CPU came out of reset - so the number of samples I requested were taken after the reset, not before it.

That is an excellent tip!

Quote:

It could be worth trying the "Slave FIFO Asynchronous Write" mode now though which is fine at 8MHz - you should just need to move your PHI2 to IFCLK, wire the pin it was originally on to GND, and run with "--ifclk=xi" instead of "-a".

Yes, this also works now! It, um, works with the jumper on. I swear this thing as gremlins. It seems that connecting A4 to GND is what makes it work for me. Jumper on or off makes no difference.

In all of these modes, though, the decoder can't decode the capture unless I explicitly tell it that "--phi2=" isn't included in the capture. Otherwise I get no output at all from the decoder. It also can't figure out that the address bus is counting in any of these captures. I feel like something still isn't quite right.

* * * * * * * *

So, I have also this cute little guy: https://www.amazon.com/dp/B077LSG5P2

It doesn't have any jumpers or any pin headers. It's got 8 channels and 2 GNDs. It works with Pulseview and sigrok-cli.

Code: Select all

paganini@cutie:~$ sigrok-cli -d fx2lafw --config samplerate=24MHz -O binary --samples 4k >sigrok.bin

gives me a perfect capture. fx2pipe doesn't seem to work with this device at all. It starts, but sits in a loop not receiving any data, just like the 16 channel board does if A4 isn't grounded. It uses a different microcontroller (cbm9002a), but it's a similar concept (8051 cores) and uses the same firmware (fx2lafw). Should I just assume there's some hardware connection that prevents it from working with fx2pipe?

[gfoot]

Paganini wrote:

In all of these modes, though, the decoder can't decode the capture unless I explicitly tell it that "--phi2=" isn't included in the capture. Otherwise I get no output at all from the decoder. It also can't figure out that the address bus is counting in any of these captures. I feel like something still isn't quite right.

By default in a 16-bit capture it thinks phi2 is on bit 15 of the data stream, but you are not sampling phi2, so all it sees there is a steady high signal level, and no falling clock edges. As you're not sampling phi2, you do need to tell it that, and then it assumes there's one sample per clock cycle and it stops trying to detect the falling clock edges.

Quote:

So, I have also this cute little guy: https://www.amazon.com/dp/B077LSG5P2

It doesn't have any jumpers or any pin headers. It's got 8 channels and 2 GNDs. It works with Pulseview and sigrok-cli.

Code: Select all

paganini@cutie:~$ sigrok-cli -d fx2lafw --config samplerate=24MHz -O binary --samples 4k >sigrok.bin

gives me a perfect capture. fx2pipe doesn't seem to work with this device at all. It starts, but sits in a loop not receiving any data, just like the 16 channel board does if A4 isn't grounded. It uses a different microcontroller (cbm9002a), but it's a similar concept (8051 cores) and uses the same firmware (fx2lafw). Should I just assume there's some hardware connection that prevents it from working with fx2pipe?

I have one of those too, it's what I used before I got the Cypress board. I've no idea whether it can be hacked in some way to be more useful. Mine actually has one ground and one pin labelled "clk" - though supplying a clock signal (phi2) on that pin doesn't seem to do anything useful. Perhaps it's an output clock.

Like yours, mine says 24MHz on the outside, but can actually sample reliably at 48MHz as far as I can tell.

The problem with this device for our purposes is that it only samples 8 bits, and doesn't do it in sync with the CPU clock - so you get a data stream showing everything it saw on the data bus, but no idea where the clock edges were. I have had some success reconstructing the clock signal based on changes in the data bus, especially with an 8-bit flipflop between the logic analyser and the data bus that itself is triggered by /PHI2, as then it's possible to look at the data stream and see where the data bits change, and extrapolate from there based on knowledge of the actual CPU clock speed and the sample rate. It's a clumsy process though! With this setup I did get some reasonable results with my 25MHz CPU clock, but my clockifier doesn't really work well at that ratio - it really needs about 3x or 4x difference between the sample rate and the CPU clock speed to work. So you're better off with the Cypress device overall.

Still, pretty neat that it can capture at that speed, even if only 8 bits.

[hoglet]

Gosh, this is a fast moving thread.

I'll try to address some of the dangling points...

gfoot wrote:

Nice! Some corrections/additions

I've made those changes.

gfoot wrote:

hoglet wrote:

Jumper J2 must be fitted, otherwise captures from fx2pipe will not work.

Other way around - it must not be fitted. I used it instead to bridge from SLWR to GND which was quite convenient!

I really don't understand why it's this way around.

There is an obvious difference between the boards:
- LCSoft: A0 is intenally pulled down by the EEPROM, and the jumper connects it to VCC
- Geeetech: A0 is externally pulled up by R1, and the jumper connects it to GND

I've been trying to work out what effect A0 has on the FX2. A0 is part of the EEPROM device address (on the I2C bus). So changing A0 (with A1/2 unconnected) is changing the device address between 000 and 001.

The FX2 Technical Reference Manual explains this on page 192. The idea is to allow the FX2 to be compatible with both small and large EEPROMs. Small EEPROMS use 8-bit addresses and large EEPROMs use 16-bit EEPROMS.

As far as I can see, all these boards are fitted with AT24C128 EEPROMs, which are large. To support these A0 should be high (device address 001).

On the LCSoft board, fitting the jumper connects A0 to VCC, allowing the device configuraion to be correctly read from the (large) EEPROM. That's consistent with my observations that when the jumper is fitted, the USB VID/PID changes to a non-Cypress ID.

On the Geeetech board, fitting the jumper connects A0 to GND, which should inhibit reading of the (large) EEPROM. I would expect this to be the setting where fx2pipe works. But it seems the oppositite is true. i.e. fx2pipe is only working when the jumper is missing.

I really don't understand how this is possible, because with the EEPROM inhibited both boards should be identical.

The only possibility I can think of is that your EEPROM is a fake. i.e. it uses an 8-bit address, even though it's marked as a 24C128.

gfoot wrote:

Regarding the issue with my reset sequence, my guess is that when my system is running from ROM the extensive clock-stretching is upsetting the FX2, perhaps because the clock has a very skewed duty cycle and very long high periods that may be equivalent to the high periods of a regular 4MHz clock, and that's below the specified 5MHz.

Yesterday I explored the valid clock ranges with a signal generator. In slave synchronous mode, when the clock is reduced, at about 3.9MHz the data transfer stops, and the FX2 appears to hang until the next reset.

Paganini wrote:

Interesting. The capture I just posted above was at 8MHz, with Ø2 connected to RDY0 (or RDY1 or whatever) using fx2pipe -a. I haven't tried to go faster than that, but I didn't realize I was already breaking the speed limit!

This is consistent with what I observed yesterday. I think I got to about 10MHz before it looked like data was being dropped. I imagine 8MHz would be fine.

gfoot wrote:

I'm sure Dave has seen this before, where it dumps some stale data at the start. Perhaps he remembers what caused it. There is a --skip option to the decoder but I have a feeling it doesn't work with these synchronous captures, only with the async ones. You can use "dd" to cut some bytes off the start though if necessary - or just ignore everything the decoder says until after the reset, like you did.

Yes, I see this frequently.

It looks like there is still a bug where the first 16KB of data received is stale.

So it looks either the firmware's FIFORESET sequence is not reliably resetting the endpoint, or this data is somehow getting buffered in the host's USB stack.

I often add the --skip=4000 parameter to decode6502 (the value is hex).

This should work regardless of the capture mode.

Dave

[gfoot]

hoglet wrote:

gfoot wrote:

hoglet wrote:

Jumper J2 must be fitted, otherwise captures from fx2pipe will not work.

Other way around - it must not be fitted. I used it instead to bridge from SLWR to GND which was quite convenient!

I really don't understand why it's this way around.

You're absolutely right, testing again now it is working fine both with and without the jumper, at least for external IFCLK captures. I'm at a loss why the jumper seemed to be the thing that made it work in the end before - the simplest explanation is that I had some of the other wiring wrong, but I spent a long time on that and was very careful with it, even after you discovered the mislabelling of the silkscreen - I was sure it still didn't work at that point. But it does seem to work both with and without the jumper now, so perhaps I did wire it wrongly, and apologies for any confusion I've caused.

The configuration I'm using now is 8-bit captures, with IFCLK connected to a slightly delayed version of the main system clock connected, "RDY0" (as labelled) connected to ground, PA5 connected to the CPU's /RESET pin, PA4 connected to my active-high clock stretching signal to make the FX2 ignore clock edges when the CPU's clock is still being held high. In case that's not clear, as it is a complication of my design:

Quote:

Yes, I see this frequently.

It looks like there is still a bug where the first 16KB of data received is stale.

So it looks either the firmware's FIFORESET sequence is not reliably resetting the endpoint, or this data is somehow getting buffered in the host's USB stack.

I often add the --skip=4000 parameter to decode6502 (the value is hex).

This should work regardless of the capture mode.

Dave

Ah OK, I thought it didn't work in this mode as it doesn't seem to have any effect for me (see below for example). It doesn't bother me though because I haven't suffered this bug for a while - I thought perhaps the way I fed /RESET into PA4 might be allowing the FX2 or fx2pipe to both be ready before having to transfer much data.

Code: Select all

gfoot@box:~/logicanalyzer/6502Decoder/fx2pipe$ xxd -g1 data25e.bin | head -2
00000000: 23 23 04 f0 04 26 23 c0 ff a2 ff 9a a9 a9 0c 8d  ##...&#.........
00000010: 60 ff 0c a9 00 85 00 00 a9 80 85 01 80 a9 00 85  `...............

gfoot@box:~/logicanalyzer/6502Decoder/fx2pipe$ cat data25e.bin | ../decode6502 -haisy -d 1 -b --vecrst=A2FFC0 --cpu=65C02 --mem=FFF | head -10
       0        0 0 23 ? ? ?
       1        1 1 23 ? ? ?
       2        2 2 04 ? ? ?
       3        3 3 f0 ? ? ?
       4        4 4 04 ? ? ?
       5        5 5 26 ? ? ?
       6        6 6 23 ? ? ?
       7        7 7 c0 ? ? ?
       8        8 8 ff ? ? ?
???? :          : RESET !!       : 9 : A=?? X=?? Y=?? SP=?? N=? V=? D=0 I=1 Z=? C=?

gfoot@box:~/logicanalyzer/6502Decoder/fx2pipe$ cat data25e.bin | ../decode6502 -haisy -d 1 -b --vecrst=A2FFC0 --cpu=65C02 --mem=FFF --skip=10 | head -10
       0        0 0 23 ? ? ?
       1        1 1 23 ? ? ?
       2        2 2 04 ? ? ?
       3        3 3 f0 ? ? ?
       4        4 4 04 ? ? ?
       5        5 5 26 ? ? ?
       6        6 6 23 ? ? ?
       7        7 7 c0 ? ? ?
       8        8 8 ff ? ? ?
???? :          : RESET !!       : 9 : A=?? X=?? Y=?? SP=?? N=? V=? D=0 I=1 Z=? C=?

[Paganini]

Here's a summary of what I think I know about using the fx2 board with fx2pipe.

For any and all modes, pin A5 must be high (it floats high automagically, but you can connect it to something like RESET\ so you can pull it low to control when the fx2 board starts sampling) and pin A4 must be low (you must ground it) in order to enable the fx2 board.

The fx2 board can capture in two modes: synchronous, where it uses its own onboard clock source, and asynchronous, where it uses an external clock source (Ø2 from the target 6502 system, for example).

Synchronous is the default mode, and can also be forced with the -s option. To use a synchronous mode capture with the 6502decoder, you must do a 16-bit capture and include the system's Ø2 as one of the sampled signals, by default, on the fx2 board's D7 pin. This mode is limited by the maximum speed of the fx2 board, which must be significantly faster than the target system's Ø2 in order to get sufficient samples per-clock-cycle. I'm not sure exactly where this limit is, but fx2 speed seems to max out at around 20MHz for 16-bit captures, which means that the target system Ø2 probably should not exceed 5MHz or so.

There are two asynchronous modes, one where the external clock is connected to the SLWR pin (to make matters worse, this pin is sometimes labeled RDY0, and sometimes labeled RDY1 on the board silkscreen), and one where the external clock is connected to the IFCLK pin. In both modes there will be one sample per system clock pulse. The advantages are that (a) the capture files will be smaller and (b) the decoder won't have to think hard about which sample is the right one to use.

In the first asynchronous mode, Ø2 is connected to SLWR. This is called "Slave FIFO asynchronous write" mode. To use this mode, give fx2pipe the -a option. This mode has a theoretical maximum speed of 7MHz, but may work up to 10MHz or so.

The second asynchronous mode is called, confusingly, "Slave FIFO synchronous write" mode. To use this mode, give fx2pipe the -s (for synchronous) option. In this mode Ø2 is connected to the IFCLK pin. To make the IFCLK pin a clock input pin, you also give fx2pipe the -ifclk=xi option. The "i" makes it sample on the falling edge, and "x" is for "external," so this really is asynchronous to the fx2 board's own clock, in spite of the -s option. In this mode, the system Ø2 must be at least 5MHz and can theoretically be as fast as 48MHz (the maximum speed that the fx2 board supports) but probably will be less due to USB limitations, etc.. In this mode, SLWR (the clock input from before) must be tied to ground.

[hoglet]

Paganini wrote:

Here's a summary of what I think I know about using the fx2 board with fx2pipe.

That's actually a really good summary!