Troubleshooting

These are more or less transcripts of troubleshooting sessions, kept here sort of as a last resort. If the FAQ and other documentation do not quite answer your questions, then perhaps something in the jumble on this page will help.

I get the error "Unknown word [lit32]" when I do a (load "arm"), the error is while parsing term.lisp.

The label 'lit32:' is in riscy.asm. I'm guessing that the assembly went wrong (per your hint below) and thus the label was not in the symbol file (riscy.lnkt), or something of that sort.

When assembling and linking riscy.asm to produce riscy.o, I get an error message about the file riscy.s being missing

earlier versions of Riscy Pygness used the GNU C compiler to preprocess the assembly source code, converting a file named riscy.S into riscy.s.

Note that file name case is ignored on Microsoft Windows, so Microsoft Windows does not distinguish properly between riscy.S and riscy.s.

This problem should not exist with the current version because the assembly source file is now named riscy.asm and the preprocessor (preasm.lisp) produces a file named riscy.s.

In case of any other similar mysteries, it might be useful to run make with the -n option, e.g.

make -n riscy.o

which will show the commands make intends to execute but without actually executing them.

Serial port problems

(See also serialport.)

Be sure to edit term.lisp to use the correct serial port name.

This might be /dev/ttyS0 or /dev/ttyS1 under Linux or COM1 or COM2 under Microsoft Windows.

Be sure the baud rate on the host is set correctly.

If the target (in riscy.asm) expects to run at 57600 bps, then under Microsoft Windows, in the terminal from which you run CLISP, you might need to run the DOS command

mode com1:57600,n,8,1

Under Linux, start up minicom, set the baudrate and turn off both hardware and software flow control, then exit, answering yes to "Leave without reset?". (Note, once you have the minicom settings the way you like them, you can save them as the default.)

Be sure riscy.asm (or its include file such as custom-lpc23xx.asm) has been adjusted for the correct clock speed. Look for equates such as PLLCLKIN, BAUDRATE, and others in the same area, e.g.

         .equ PLLCLKIN, 12000000  ;  Main crystal clock frequency
         .equ BAUDRATE, 115200
       

Be sure the serial port's DTR and RTS lines are not holding the target in reset or in BSL (bootstrap loader) mode.

Some target boards use the serial port's DTR and RTS signals to make rebooting and burning the flash easier by letting a program on the PC force reset and bootloader mode automatically. If these signals are connected on your target board (such as the Olimex P2378) and if your serial port asserts either DTR or RTS (as does minicom) then your target will never run unless you disconnect those lines (e.g. by removing the two shorting blocks on the Olimex P2378 board).

Forth error when running arm.lisp from the makefile

This is probably an error in one of the *.forth files that *arm.lisp* is compiling. To see the error better, you could load arm.lisp "manually". That is, start CLISP then (load "arm"). You should hit the same error but would then have the interactive CLISP facilities available so you could type :w and :u etc. to see what was happening at the time. Usually this is not necessary as the error message will direct you to the problem.

Example, I got this error from the makefile:

      ./arm.lisp

      problem in forth-number in parse.lisp
      *** -
      Unknown word: , ?
      last-name: NIL, current-file: riscy.forth
      Next line: I have some uncertainty whether
      make: *** [combo.bin] Error 1
     

It says that the unknown word is a comma and it says the last-name is NIL and the file that was being compiled at the time is riscy.forth.

This suggests there is a comma (??) somewhere before the first Forth label in the file riscy.forth. Further more, the error then reads ahead a little, showing some text (I have some uncertainty whether) which surely does not look like Forth code.

A quick look in riscy.forth shows that text in the middle of what should have been a comment. Aha, there are some extra (nested) parentheses that cause the comment to be ended prematurely. I changed the inner parentheses to square brackets (or anything but parentheses), reloaded arm.lisp and all was well.

Errors or failure when trying to burn combo.bin into the flash using the JTAG cable and openOCD

You might have run burn.sh from makefile with

      make combo.jtag
      

or directly from a shell prompt with

      ./burn.sh
      

In either case, whether you get error messages or not, something is funny and the target does not run or does not run correctly.

There could be a problem in your code or it could be failure to program the flash. The burn.sh script is rather crude and sometimes needs to be run several times for it to work.

Another option is to run openOCD manually. See the faq for details.

nothing works or nothing helps

See the section in riscy.asm about blinking an LED 3 or 4 times. You might uncomment that code, which should cause the target board's LED to blink 3 or 4 times before any serial port activity occurs.

If you do not have an LED on your board, you can still use the LED flashing code to toggle an I/O pin on your board and check it with a logic probe or oscilloscope. Be sure to pick an I/O pin that is available and set it up correctly to be an output pin.

Also, see custom-lpc23xx.asm for the commented out code for a echo loop. You could uncomment it (if you are using an lpc23xx chip) or else add it to the custom-*.asm file you are using.