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?

Make sure to unplug/replug each time.

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

Dave

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


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.

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.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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:


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


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


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)

I think it's working!

I threw together a little test rig this afternoon: Tidy, innit? I put a NOP testing ROM in.



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.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

That's great!


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.


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.


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


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

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

That is an excellent tip!

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

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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.


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.

Gosh, this is a fast moving thread.

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


I've made those changes.


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.


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.


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.


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

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:




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.

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.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

That's actually a really good summary!