<< Previous | Index | Next >>

> ## Chapter 12. Troubleshooting Tips for New Rabbit-Based Systems

> If the Rabbit design conventions were followed and Dynamic C cannot establish target communications with the Rabbit 2000-based system, there are a number of initial checks and some diagnostic tests that can help isolate the problem.

> ### 12.1 Initial Checks

> Perform the first two checks with the /RESET line (pin 37) tied to ground.

> 1. With a voltmeter check for VDD and Ground (including VBATT ) on the appropriate pins.

> 2. With an oscilloscope check the 32.768 kHz oscillator on XTALA1 (pin 40). Make sure that it is oscillating and that the frequency is correct.

> 3. With an oscilloscope check the main system oscillator by observing the signal CLK (pin 1). With the reset held high and no existing program in the flash memory attached to the processor, this signal should have a frequency one eighth of the main crystal or oscillator frequency.

> ### 12.2 Diagnostic Tests

> The cold boot mode may be used to communicate with the target system without using Dynamic C. As discussed in Section 4.1, in cold boot mode triplets may be received by serial port A or the slave port. To load and run the diagnostic programs, the easiest method is to use the programming cable and a specialized terminal emulator program over asynchronous serial port A. To use the slave port requires more setup than the serial port method and it is not considered here. Since each board design is unique, it is not possible to give a one-size-fits-all solution for diagnosing board problems. However, using the cold boot mode allows a high degree of flexibility. Any sequence of triplets may be sent to the target.

> #### 12.2.1 Program to Transmit Diagnostic Tests

> The file `SerialIO_1.zip` is available for download at:

>     www.rabbitsemiconductor.com/support/downloads/

> The zip file contains the specialized terminal emulator program `serialIO.exe` and several diagnostic programs. The diagnostic programs test a variety of functionality, and allow the user to simulate some of the behavior of the Dynamic C download process.

> After extracting the files, double click on `serialIO.exe` to display the following screen.

> Click on Help at the top left-hand side of the screen for directions for using this program.

> A diagnostic program is a group of triplets. You can open the provided diagnostic programs (those files with the extension `.diag`) with Dynamic C or any simple text editor if you would like to examine the triplets that are sent to the target. Also, `serialIO.exe` has the option of sending the triplets a line at a time so you can see the triplets in the one-line window next to the Transmit button before they are sent.

> NOTE | Connecting the programming cable to the programming connector pulls both SMODE pins high. On reset this allows a cold boot from asynchronous serial port A. The reset may be applied by pushing the reset button on the target board, or by checking then unchecking the box labeled DTR when using `serialIO.exe`.

> In the following pages, two diagnostic programs are looked at in some detail. The first one is short and very simple: a toggle of the status line. Information regarding how to check the results of the diagnostic are given. The second diagnostic program checks the processor/RAM interface. This example provides more detail in terms of how the triplets were derived. After reading through these examples, you will be able to write diagnostic programs suited for your unique board design.

> #### 12.2.2 Diagnostic Test #1: Toggle the Status Pin

> This test toggles the status pin. It is available as `StatusTgl.Diag`, one of the diagnostic samples downloaded in `ser_io_rab20.zip`.

> 1. Apply the reset for at least ¼ second and then release the reset. This enables the cold boot mode for asynchronous serial port A if the programming cable is connected to the target's programming connector.

> 2. Send the following sequence of triplets.

>        80 0E 20      ; sets status pin low
>        80 0E 30      ; sets status pin high
>        80 0E 20      ; sets status pin low again

> 3. Wait for approximately ¼ second and then repeat starting at step #1.

> While the test is running, an oscilloscope can be used to observe the results. The scope can be triggered by the reset line going high. It should be possible to observe the data characters being transmitted on the RXA pin of the processor or the programming connector. The status pin can also be observed at the processor or programming connector. Each byte transmitted has 8 data bits preceded by a start bit which is low and followed by a stop bit which is high (viewed at the processor or programming connector). The data bits are high for 1 and low for 0.

> The cold boot mode and the triplets sent are described in Section 4.1. Each triplet consists of a 2-byte address and a 1-byte data value. The data value is stored in the address specified. The uppermost bit of the 16-bit address is set to one to specify an internal I/O write. The remaining 15 bits specify the address. If the write is to memory then the uppermost bit must be zero and the write must be to the first 32 KB of the memory space.

> The user should see the 9 bytes transmitted at 2400 bps or 416 µs per bit. The status bit will initially toggle fairly rapidly during the transmission of the first triplet because the default setting of the status bit is to go low on the first byte of an opcode fetch. While the triplets are being read, instructions are being executed from the small cold boot program within the microprocessor. The status line will go low after the first triplet has been read. It will go high after the second triplet is read and return to low after the third triplet is read. The status line will stay low until the sequence starts again.

> If this test fails to function it may be that the programming connector is connected improperly or the proper pull-up resistors are not installed on the SMODE lines. Other possibilities are that one of the oscillators is not working or is operating at the wrong frequency, or the reset could be failing.

> #### 12.2.3 Diagnostic Test #2

> The following program checks the processor/RAM interface for an SRAM device connected to /CS1, /OE1, /WE1. The test toggles the first 16 address lines. All of the data lines must be connected to the SRAM and functioning or the program will not execute correctly.

> A series of triplets are sent to the Rabbit via one of the bootstrap ports to set up the necessary control registers and write several instructions to RAM. Finally the bootstrap termination code is sent and the program begins executing instructions in RAM starting at address 0x00.

> The following steps illustrate one way to create a diagnostic program.

> 1. Write a test program in assembly:

>        main(){
>        ;
>        #asm
>        boot:
>           ld hl,1
>           ld b,16
>        loop:
>           ld a,(hl)
>           add hl,hl   ; shift left
>           djnz loop   ; 16 steps
>           jp 0        ; continue test
>        #endasm
>        }

> 2. Compile the program using Dynamic C and open the Assembly window. The disassembled code looks like this:

> 1. The opcodes and their data are in the 2nd column of the Assembly window. Since we want each triplet loaded to RAM beginning at address zero, create the following sequence of triplets.

>        ; code to be loaded in SRAM
>        00 00 21
>        00 01 01
>        00 02 00
>        00 03 06
>        00 04 10
>        00 05 7E
>        00 06 29
>        00 07 10
>        00 08 FC
>        00 09 C3
>        00 0A 00
>        00 0B 00

> 2. The code to be loaded in SRAM must be flanked by triplets to configure internal peripherals and a triplet to exit the cold boot upon completion.

>        80 14 05     ; MB0CR: Map SRAM on /CS1 /OE1 /WE1 to Bank 0
>        80 09 51     ; ready watchdog for disable
>        80 09 54     ; disable watchdog timer
>        .
>        .            ; code to be loaded in SRAM goes here
>        .
>        80 24 80     ; Terminate boot strap, start executing code at address zero

> The program, `serialIO.exe`, has the ability to automatically increment the address. Instead of typing in all the addresses, you can use some special comments. They are case sensitive and must be at the beginning of the line with no space between the semicolon and the first letter of the special comment.

>     ;Address nnnn
>     ;Triplet

> The first special comment tells the program to start at address nnnn and increment the address for each transmitted data byte. The second special comment disables the automatic address mode and directs the program to send exactly what is in the file. The triplets shown in #3 may be rewritten as:

>     ;Address 0000
>        21 01 00         ;ld hl,1
>        06 10            ;ld b,16
>        7E               ;ld a,hl
>        29               ;add hl,hl
>        10 FC            ;djnz loop
>        C3 00 00         ;jp 0
>     ;Triplet

Rabbit 2000 Designer's Handbook | << Previous | Index | Next>> | rabbit.com