Loading Code into DSPs for the L1.5 Cal Trig ---------------------------------------------- 1-APR-1994 Introduction ------------ This file describes the steps that are required for loading the L1.5 Cal Trig code into the DSPs (both Local and Global DSPs). Loading the code into the DSPs involves the following steps: (1) Halting the DSPs (2) Placing the DSP code into the Dual Port Memory (3) "Booting" the code to the DSPs via the On-Chip ROM Boot Loaders. Note that the code will begin executing immediately after it is loaded. (1) Halting the DSPs All DSPs should be halted by the TCC before trying to load code into any one of the DSPs. This minimizes the chance that a DSP can corrupt the On-Chip ROM Boot Loader-readable program image while it is stored in the Dual Port Memory (before it is actually "booted" into a DSP). The DSPs should be halted by asserting their RESET lines (note that these are ACTIVE-LOW lines, i.e. asserted by bringing them low) The TCC can halt one DSP at a time by writing to the Boot Control Register of each DSP. At the same time the TCC uses the Boot Control Register of each DSP to halt the DSP, it can set the IIOFx lines (also available via the Boot Control Register, these lines are used at boot time to determine the source of the On-Chip ROM Boot Loader Readable image) to the appropriate state specifying the Dual Port Memory as the source of the program to be booted into the DSPs. The Boot Control Register is described on pages 25-28 of the Hydra Manual. A quick summary is below: Boot Control Register Hydra Base Address + 10800h [DSP #1] VME addresses: Hydra Base Address + 10804h [DSP #2] Hydra Base Address + 10808h [DSP #3] Hydra Base Address + 1080Ch [DSP #4] (i.e. Boot Control Register for DSP A1 is at VME Address $A10800) The Boot Control Register bits are described in the Hydra-II manual. These are 8-bit registers which should be accesses using 32-bit (longword) writes (NOT 8-bit writes). The Boot Control Register is only visible in VME address space. The use of the On-Chip ROM Boot Loader is described in Section 13.2 of the TMS320C40 User's Guide. I write 00000010h to the Boot Control Register to halt the DSP and specify Dual Port Memory (Base Address in DSP address space of the Dual Port Memory is 8000 0000h) as the program source. See the file TRGBOOK:ARIEL_HARDWARE_SOFTWARE.LBK for more details (specifically, see the 3-NOV-1993 entry). Note that the DSPs must be halted sequentially (i.e. they cannot all be halted in parallel), but they can all be halted before proceeding to the next step. (2) Placing the DSP code in the Dual-Port Memory After the DSPs are halted, an On-Chip ROM Boot Loader-readable image of the DSP code for 1 DSP can be placed in the Dual-Port Memory, starting at the Dual Port Memory base address (recall that the Dual Port Memory Base Address is the same as the Hydra-II Base Address, i.e. VME address $A00000 for Hydra-II Card A). It is only possible to load the code for one DSP at a time. This is because the Boot Loader-readable image must be stored beginning at the base of the Dual Port Memory (i.e. it is not possible to specify an offset into the Dual Port Memory for the Boot Loader to use). Therefore, since each DSP will be loaded with a different executable, we must load each executable separately and sequentially (in theory it is possible to boot DSPs on multiple cards concurrently but that is probably a needless complication). Recall that the Boot Loader-readable image of the program is generated by the Assembler, Linker, and Hex Converter packages on the PC. The TCC is not allowed to modify the Boot Loader-readable program image. During this phase of loading, the TCC does not need to modify the Boot Control Registers of any DSPs. (3) "Booting" the code to a DSP via the On-Chip ROM Boot Loader After the code for a DSP is placed into the Dual Port Memory, that DSP (and ONLY that DSP) should "boot-load" the code. This is accomplished via the On-Chip ROM Boot Loader, which reads the program image stored in Dual Port Memory, moves it to the memory locations specified in the Boot Loader-readable image (i.e. some to on-chip RAM, some to Local SRAM, some to Global SRAM), and begins executing the code starting at some specified address [again this address is specified in the Boot Loader-readable program image stored in Dual Port Memory]). This booting is performed by again writing to the Boot Control Register of the appropriate DSP. See the references specified above for details of the Boot Control Registers and the On-Chip ROM Boot Loader. I typically write 00000030h to the Boot Control Register to bring the DSP out of its RESET state and begin loading code from the base of the Dual Port Memory. Again, note that immediately after the code is loaded into the DSP, the code begins executing. The code will perform a few operations necessary to get complete control of the C40 chip, and then it will place the Status_OK code into the first longword of its "DSP to TCC Status" Block. The MSByte of this longword will indicate DSP ID, and the LSByte of this longword will be 0. The two middle bytes are undefined and will also be 0. Once TCC has seen the Status_OK code from a DSP, it knows that the DSP has received its code and is waiting for its Parameters. I think a typical sequence of loading code to all of the DSPs would go: (A) Halt all DSPs as specified in Step (1) (B) Place DSP code for a single DSP into the appropriate Dual Port Memory as specified in Step (2) (C) "Boot-load" the code into that DSP as specified in Step (3) (D) Repeat Steps (B) and (C) until all DSPs are loaded.