Troubleshooting Upgrade

Logs

If the web interface is working, (http://tipi:9900) there is a logs section in the WEB-UI. Both the tipi.log and system daemon.log are available there.

If not, ssh into the tipi, as user tipi, and there are 2 logs that typically matter:

• /var/log/tipi/tipi.log
• /var/log/daemon.log

Triage

Your TI-99/4A is old... it may lock up during upgrade or otherwise crash. Weather, and all that. If the spinner in TIPICFG stops spinning, that does not mean the upgrade is complete.

ssh into the tipi, as user tipi

sudo tail -F /var/log/daemon.log

Watch that for a little bit... it may still be making progress. Typically you'll see log statements prefixed with the 'tipisuper' service name. This means it is still running. So just be patient. Typically the last thing you see is the tipiweb service reporting from flask that it is ready.

If you think it is complete, try this command:

sudo systemctl status 'tipi*'

You should see tipi.service, tipiweb.service, tipimon.service, and tipiwatchdog.service all running.

Manually Run the tipi.service

If there is no /var/log/tipi/tipi.log, then service startup is failing somewhere... you can manually run the service and see the output to the terminal:

sudo systemctl stop tipi.service
cd /home/tipi/tipi/services
./tipi.sh

That temporarily stops the tipi.service from being in the Operating System's control. Then we run the service script. It should output something similar to:

checking for operation mode...
TIPI_SIG_DELAY=150

The value of the TIPI_SIG_DELAY may vary depending on the type of Raspberry PI you are using.

Further output should end up in the /var/log/tipi/tipi.log. But of course, if you are here, that didn't happen. So hopefully your errors will indicate to the support forum, what needs to be done to remedy your issues.

Note, sudo systemctl stop tipi.service was temporary. You may restore that with sudo systemctl restart tipi.service, however it will restart automatically on reboot.

Re-upgrade

If that is not the case, something went horribly wrong. You can attempt to recover by re-running the post-upgrade.sh script:

sudo /home/tipi/tipi/setup/post-upgrade.sh

This will cause it to reconfigure the dependencies for the python services, and restart them. If this still fails, you can report the issue here in github as an issue, reach out on the Atariage support thread, or backup your TI-99/4A files that are on the tipi share (also in /home/tipi/tipi_disk ) and start with a fresh SD card image from the jedimatt42.com downloads page.

Troubleshooting TIPI Hardware

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:

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

2. 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 program data from the PI to the TI. This exercises the communication with the PI quite well.

3. 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 interferance with other addresses in the system. Or an unprogrammed CPLD.. If I recall, that seems to leave the databus active.

You can also read and write the TIPI registers from the Raspberry PI to validate that communication is working. See Low Level Testing for more detail. You must be able to ssh into the PI as user tipi to perform this test while the TIPI is wired to the PI.