Debugging - nealcrook/multicomp6809 GitHub Wiki
Here are a miscellaneous set of tips that may (or may not) help you to debug your system
Start Simple
Start with an exact copy of Grant's design, get that working and then progress to a more complex system. For example, start with the keyboard/VDU and internal RAM. Externally, first wire up the VGA Connector and get video working, then wire up the connections for the keyboard and get that working. Next, wire up the external memory and get that working - then disable the internal memory (which frees up memory for the 80-column video). Finally wire up the SDcard and get that working.
Hardware Debug
Video
With the Multicomp (by which I mean the FPGA board and your external connections/components) powered down, plug in the VGA monitor. The monitor should report "no signal" or similar (sometimes an LED changes color to indicate no signal).
When you power-up the Multicomp, it should start to generate video, and the monitor should indicate this. Even if you don't have a "working system" you should be able to see if you're getting video or not. If you're getting video this tells you power is good and the clock is good and your connections are (probably) good. The "clear screen" is done under hardware control so you should never see a screen of junk, unless you have code running and it has gone haywire.
The video sub-system is not reset by the reset switch, so pressing and holding reset will not cause the monitor to lose signal, and will not cause the screen to be cleared again.
PS/2 Keyboard
When you power-up the Multicomp, the Caps-Lock LED on the keyboard should light up. Tapping the Caps-Lock key should toggle the LED. Tapping the Num-Lock key should cause the Num-Lock LED to toggle. All of that is controlled in hardware as a result of signalling between the keyboard and the video sub-system.
If the keyboard LEDs don't behave in this way, there are two things to check. First, check the wiring and the pullup-resistors on the clock and data connections. Second, it's possible that your keyboard is not getting a high enough supply voltage. Grant's design has the keyboard powered at 3.3V which is low. Some keyboards apparently work. Mine did not. The fix is to power the keyboard from 5V (just the keyboard; keep the pullups wired to 3.3V). Unfortunately there doesn't seem to be a 5V connection on the FPGA board main connections (I used a flying lead across to the 5V side of the FPGA regulator).
A potential problem with powering the keyboard at 5V is that the keyboard might overdrive the SCLK/SDATA signals relative to the 3.3V supply (and 3.3V-tolerant inputs of the FPGA). If you have a multimeter you can measure the voltage on the pullup relative to 0V. If you find it is 5V (or 4 point something) you should consider putting a 3.3V zener diode to ground on each of the SCLK/SDATA signals to avoid stressing the FPGA inputs (this could lead to premature part failure). The Zener should be reverse-biased so that it breaks down at 3.3V and acts as a clamp.
RAM
If the Monitor and Keyboard are working, your boot ROM (BASIC by default) should be producing a sign-on message and all should be working.
When I built my system it worked fine with internal memory, and seemed to work fine with a combination of internal memory and external memory, but failed when I tried to run with just external memory. The problem took several days to track down. I eventually traced it to a short between two adjacent pins on the FPGA board, which caused 2 of the RAM address lines to short, causing an addressing problem. I could not find the short (it might have been under-etching on the PCB) and eventually "fixed" it by reassigning pins for both of the affected address lines. The moral of the story is that you need to check everything and the problem still might not be your fault!
If you build the system using the Camelforth ROM, getting to the sign-on message indicates that you are already running the inner loop of the FORTH interpreter successfully. In the emulator I see 1007 instructions executed to get you to that point, including at least 100 stack (memory) reads and writes. There are also 181 JMP [,Y++] -- change of program flow, based on value read from RAM. All this adds up to suggest that the memory is working fine - and that the processor is working fine.
There is a simple ascending/descending memory test in Camelforth. Invoke it like this:
HEX
800 E000 100 PASSES
800 is the start address, E000 is end address, 100 (256 decimal) is the number of passes. It prints "." after each pass. Don't test below 800 because the FORTH stack etc. live there. The ROM starts at E000 (if you did 800 E001 2 PASSES you will see errors from attempts to access E001). It should take about 2s per pass.
SDcard
It seems that not every SDcard works correctly with the multicomp SDcard controller (even if the card seems to work perfectly on your PC). Grant's original sd_controller.vhd design only supported small (2Gbytes or less) cards. The current sd_controller.vhd in my design also supports SDHC cards. None of the designs support SDXC cards. Here is a simple test from Camelforth. It will overwrite data on the card so //don't do it on a card that contains data you want to keep.//
Power-cycle so you get the Camelforth start-up banner. The SDcard needs to be inserted //before// you power-up (there is no hot-swap). There is no need to type the comments -- which start "".
HEX
2 SDLBA2
1900 E000 SDWR \ FIRST WRITE TO BLOCK FROM ROM AT E000
1900 3000 SDRD \ READ BACK THE DATA WE WROTE, TO 3000
1900 E000 SDWR \ SECOND WRITE TO BLOCK FROM ROM AT E000
1900 3000 SDRD \ READ BACK THE DATA WE WROTE, TO 4000
E000 3000 100 S= . \ COMPARE 100 BYTES. "." PRINTS THE RESULT: 0 MEANS MATCH
E000 4000 100 S= .
3000 4000 100 S= .
The last three lines do comparisons between memory regions.
First one is 0 if the first write read back the same data as was written Second one is 0 if the second write read back the same data as was written Third one is 0 if the first write read back the same data as the second write
You should see three "0".
Other things to check
Locate the .pin file (in your altara project's output_files/ directory) and check that all the pin assignments of the FPGA match up with your external connections.
Software Debug
If you are having trouble getting CUBIX or FLEX up and running there are some step-by-step debug tips at the end of these pages: