Troubleshooting the logging function of the Virtual 2315 Cartridge Facility

DEBUGGING CAPABILITIES BUILT INTO THE V2315CF

The Virtual 2315 Cartridge Facility (V2315CF), built around an FPGA, a DRAM chip and a Raspberry Pi PICO, has a serial debugging output available that logs both status and error messages as the unit does its work. It has the capability to log each seek, read and write to the same serial port if I type the letter L into the serial terminal to request logging. 

The FPGA logic that processes read, write and seek operations emits a short pulse for each of those events. These are ORed together and output on an FPGA pin as CMD_INTERRUPT. That pin is routed to pin 6 of the PICO, which is general purpose IO (GPIO) 4. The FPGA is communicating with the PICO over an SPI link, driven by the PICO. 

The PICO is configured to call a routine when there is a rising edge on GPIO pin 4. That routine requests data from the FPGA over SPI and then issues a message on the serial port that indicates whether it was called due to a seek, a read, or a write, accompanied by the current cylinder, head and sector. 

LOGGING IS FAILING TO WORK

All the software in the PICO and the logic in the FPGA appears correct. It used to work a few months ago, but recently it does not. I put a oscilloscope on GPIO pin 4 (CMD_INTERRUPT). The line is steadily high, which is not correct. Without a rising edge, there will be not interrupt and the callback routine won't execute to log the status. 

The same logic that emits the pulses for seek, read and write also drives the indicator lamps RD, WT and SEEK on the V2315CF front panel. Those indicator lights work correctly! I don't know why the signal isn't working correctly into the PICO.

There are a few possibilities. I have already replaced the PICO so it is not that bit of hardware. There could be a short somewhere on the PCB that is driving CMD_INTERRUPT high in spite of it being logically low in the FPGA code. There could be a failure in the FPGA chip itself that is producing a high output incorrectly. There could be some weird Lattice toolchain issue causing the FPGA to not do what I coded. Or, there could be some other kind of unexpected gremlin.

QUICK MODIFICATION TO SEE WHICH OF THE THREE OPERATIONS ARE HIGH

If there is some flaw in the FPGA logic such that one of the lines - seek, read or write - that should be pulsed high temporarily is instead permanently high, I can at least narrow things down to which line is bad. I modified the FPGA and the PICO to add a new SPI transaction type which will return the seek, the read and the write status lines separately. The PICO will output that information periodically with its normal status message over the debugging serial link. 

What I observed was that my output indicated that all the signals were low inside the FPGA, thus the output from the FPGA should be low, however it was logic high continually. 

TRYING THE OTHER V2315CF UNIT

I am building two V2315CF units, one for the Infoage/Vintage Computer Federation museum and one for the System Source Museum. I therefore have two main units constructed. If I swap them on the 1130 I am debugging with, I can rule out FPGA hardware and motherboard trace issues, as the problem will only remain if it is a defect in the logic in the FPGA or the code in the PICO or the toolchain. If the problem disappears, I then need to do some detective work to identify the actual failing part. 

When I ran with the other V2315CF unit, logging worked perfectly. It is therefore an issue with the FPGA or the board traces. As this works well other than the logging, I wouldn't replace the FPGA to cure this, but if I spot something on the board that can be remedied I will.