Debugging SCORE UCCs on PowerPC

Product Family: SCORE
Target CPU: PowerPC
Language: Any
Host: Any

Debugging the UCC (User Configurable Code or Board Support Package) can be challenging, since no target code can be debugged with the SCORE Multi Language Debugger, if the UCC is not working.

In the event of a UCC bug, it is recommended that the user start by turning on the UCC test output by replacing the following line in initialize.c:

ddci_tstio_install( &ddci_null_driver );

with either

ddci_tstio_install( &ddci_com1_int_buf_driver );

if the UCC uses interrupt driven I/O, or

ddci_tstio_install( &ddci_com1_non_int_driver );

if polled I/O is used.

If there is no output at all, then always use the second option.

The UCC startup code will then provide progress output on the serial line. The progress output that appears before the serial communication device has been initialized may have to be commented out, if the serial device has not been set up by some earlier board firmware initialization.

The UCC contains functionality for the following:

1. Logical and physical drivers.
2. Hardware Exceptions.
3. Essential Peripheral Units: UART, Real-Time Clock, and Interrupt Controller.
4. Caching.

Item 1) is hardware-independent and has only been placed in the UCC to make it easy to reconfigure the I/O, e.g. to switch between polled and interrupt-driven I/O.

Item 2) is specified by the PowerPC architecture, it is common to all PowerPC processors.

These two parts of the ucc are not likely to have problems, since they are it are basically common for all UCCs.

Items 3) and 4) are the areas where closer examination will be required if the UCC startup hangs.

Peripheral units will often be legacy units like the PC16650 UART and 8259 interrupt controllers or units that are software compatible with these units. It will often be possible to find suitable initialization code in one of the preconfigured UCCs. The biggest challenge posed by the peripheral unit initialization can be to ensure that there is access to the peripheral unit. On modern COTS boards with multiple buses, it may be necessary also to initialize bridge chips connecting the buses before the peripherals are accessible to the PowerPC CPU. The preconfigured UCC for the Motorola MVME2400 board for example needs to set up the HAWK bridge chip before the interrupt controller can be initialized.

If the board hangs right after the cache has been enabled it is most likely due to an error in the initialization of the IBAT and DBAT registers contained in the file set_simple_protection_bats.S. It is recommended to let the entire RAM area be covered by both IBATs and DBATs and it is essential that the address ranges used for I/O are covered by DBATs, but these blocks shall not be cached. Also please note that the start address of the BAT block must be aligned to the size of the BAT block.

Another pitfall that may lead to the board hanging when the cache is turned on, is that the caching may already be active, if the UCC is started from a firmware monitor. In that case, the contents of the data cache shall be written back to RAM before the cache is invalidated as part of the initialization. An example of this can be found in the preconfigured UCC for Motorola MVME2400.

After your debugging is complete, restore the file initialize.c to its original state by replacing the line ddci_tstio_install( &ddci_null_driver ); to prevent the progress text from cluttering the display.