Many DSP56001 designs require that the target hardware boot from an external byte-wide EPROM. Often, getting the user's code into bootable form raises questions regarding the use of overlay addresses (i.e., separate runtime and loadtime address counters) and the generation of files in formats which will be accepted by standard EPROM programming equipment. ** DSP56001 bootstrap operation ** Upon leaving reset, the DSP56001 samples the MODA/IRQA and MODB/IRQB pins in order to determine the initial operating mode. If MODA/IRQA is at a logic "1" and MODB/IRQB is at a logic "0", the device will enter the bootstrap mode and will then sample Data Bit 23 at address P:$C000. If this bit is read as a logic "0", the bootstrap process will expect to receive code through the Host Interface of the DSP56001. If this bit is sensed as a logic "1", then the device will load its initial operating instructions from byte-wide memory located on the external data bus. When booting from external byte-wide memory, the DSP56001 first retrieves the data on bits 0-7 of the external data bus at address P:$C000. This byte is assumed to be the low byte of a 24-bit word. The bytes at P:$C001 and P:$C002 are then read and assumed to be the middle and upper bytes (respectively) of the first 24-bit instruction word. The first 24-bit instruction word is then constructed from these 3 bytes and placed into on-chip Program Memory at address p:0000. The next 3 bytes read from the EPROM at P:$C003, P:$C004 and P:$C005 are used to construct the instruction word which is placed into on-chip Program memory at P:0001. This process continues until the entire 512 words of internal Program Memory are filled from EPROM data. When this on-chip program memory has been loaded, the DSP56001 starts executing code at P:0000. It is crucial that the module be written such that orderly execution begins at this address, P:0000, the Reset Vector. *** a simple example *** A simple example will serve as our vehicle for demonstrating the steps necessary to generate a bootable EPROM. The entire code module for this example appears boot.asm. The main task of this module is to toggle the LSB of Port-C so that the user may confirm proper boot operation through an oscilloscope attached to that I/O pin. This simplistic piece of code would normally contain the user's application or a more sophisticated loader which would initialize external X:, Y; and/or P: memory from a different portion of the EPROM. The ORG directive merits discussion. In particular, the second ORG directive uses some interesting techniques. In this case, we need to assemble code which will EXECUTE in P:memory at an address referred to by the symbol "main". This symbol has been previously set to the value $50, so this code will be assembled to start at P:$0050. The EPROM which contains the program will be mapped into the DSP56001's Program Memory at P:$C000, due to the dictates of the device bootstrap procedure. This dilemma is solved through the second portion of the ORG directive where a loadtime address is specified. Recall that the EPROM is a byte-wide device and requires three sequential addresses for each 24-bit word stored in this non-volatile device. The second element in the ORG directive is an expression which computes the appropriate EPROM address for this portion of the code. This expression starts by multiplying the beginning address of this segment of code by 3. This compensates for the fact that 3 addresses were occupied for each single 24-bit word located in EPROM. Additionally, the EPROM begginning address of $C000 was added to this product in order to offset the addresses as required by the EPROM mapping. At this point, the assembler has been directed to generate code for execution at P:$0050 but the actual addresses sent to the load file start at p:$C0F0. This is the proper address for the first byte (the lower byte...) which will used to construct the 24-bit word destined for P:$0050 in the DSP56001's on-chip P:RAM. A simple warning message is conditionally assembled in the event that the user's code size exceeds the amount of P:RAM on-chip. This may be particularly helpful during code development where code size is continuously being altered. **** the interrupt vector table **** The first $40 locations of DSP56001 on-chip P:memory are used for interrupt vectors. It is a good practice to initialize these locations in such a manner as to gracefully accomodate unexpected interrupts. Since booting the DSP56001 from EPROM will always fill these locations, initializing the vectors has no effect on the boot timing. Perhaps the easiest way to accomplish this initialization is the fill the vectors with NOPs as is shown in the example. As a minimum, this technique reduces unexpected interrupts to Fast Interrupts in which two NOPs are executed and the machine returns to the normal execution stream. The disadvantage of the approach is that the errant behavior will add a slight delay to the execution of the main program while the Fast Interrupt is serviced. *** making a EPROM programmer compatible file *** The program can be assembled with a single command line as follows: asm56000 -a -b -l boot This produces a listing file (boot.lst) as well as the load file boot.lod. If you are using version 4 or later of the Assembler/Linker, you will need to use the CLDLOD utility to convert the file to a .LOD file; CLDLOD is available for download in "software/tools." The utility SREC can be used to generate S-RECORD formatted output files which are used by most standard EPROM programming hardware. The following command line will generate a single S-RECORD file (boot.p) which will be ready to send to the EPROM programmer: srec boot The output file from this utility is an ASCII file (S-RECORDS are ASCII). Note that after the standared S-record preamble information (including the EPROM address), the data is presented in the order of least-, middle- and then most-significant byte. This is the proper order for the bootstrap process on the DSP56001. Note that the next-to-last record in boot.p points to address $C0F0, an address which is NOT contiguous with the previous records. The code has specified that NOPs are to be place in the first $40 address, but then the next segment of code is to be placed in a different portion of the EPROM. The contents of the addresses which occur between the end of the first segment and the start of the second segment of code will NOT be programmed and will generally contain $FF - the default value for non-programmed (i.e., erased) EPROM bits.