Troubleshooting - jgparker/tipi GitHub Wiki

Troubleshooting TIPI Hardware

Unchanged from Jedimatt42's version, but TIPI/32K specific debugging to be added...

Prerequisites

First: 99% of TIPI software including the config tool requires working 32K memory. Verify your memory is glitch free with my memory test: 32k memory test Testing the TIPI

CALL TIPI is the simplest program that exercises the most functionality:

The address decoding, ROM enable, ROM banking, and buffer enable in the CPLD all have to work, so you can get to the extension to BASIC ( the CALL TIPI command )

The program you see is just TIPI.TIPICFG being loaded from the Pi from a TI_FILES using the LOAD disk io operation - it only takes 2 seconds, but streams 16k of program data from the Pi to the TI. This exercises the communication with the PI quite well.

Once the program is running it lives in the 32k memory, and continues to gather more information: Reading the ROM (which also performs a CRU scan) to get the DSR build timestamp. Examines some CRU bits. Loads records from 2 files PI.STATUS and PI.CONFIG just like any other TI program would load records from a file.

So it exercises all of the TIPI boards, and most of the fundamental Pi side functionality.

Isolating hardware defects

If I need to look lower level, I use EASY BUG from mini-memory cartridge.

Knowing the crubase of the TIPI ( usually >1000 with no jumper when I'm testing, >1100 if meant as a side port replacement for floppies )

C1000 - this command lets me see state of crubits. TIPI has 4. you can press enter 3 more times and should see them all zero initially. If any are already 1, then there is usually something wrong with the soldering on the bottom edge of the CPLD.

C1000 again, and enter 1 - this enables the DSR ROM, you should see the TIPI LED activate.

M4000 - go to the memory address for DSR ROMS. The bytes for the TIPI should be there. Press enter a bunch to see several of the bytes. first 2 should be AA and 01 - I usually look at 12 bytes or so, and check that I'm seeing both odd numbers and even numbers and nothing that looks like a particular bit is stuck on the databus. If you don't see anything resembling good - like just some 00, or simply an echo of the LSB of the address, like 01, 02, 03, 04 values in sequence, then there is likely something wrong with the soldering on the 74HCT245 chip. If you do see something that looks like stuck bits, it is probably the soldering on the right hand side of the CPLD.

M5FFF - this is one of the registers we can write to from the 4A and read back. So enter a value like 55 and AA ( alternating bit patterns 01010101 and 10101010 ) If you don't get the value back that you entered ( by entering '.' and then 'M5FFF' again to read that address ) but the DSR ROM seems fine, then 99% of the time, this is the soldering on the right hand side of the CPLD.

If the 4A won't boot when a TIPI is in, it is usually a short across pins on the bus transceiver chips, the '245, and 3 '244s causing interference with other addresses in the system. Or an unprogrammed CPLD. If I recall, that seems to leave the databus active.