Using the D800K001 bootloader in SPI Slave mode

This page is an extension to the existing application report [1] and provides a detailed description of the boot procedure from host perspective when SPI Slave boot mode is selected on the DSP side.

Generating an Application Image Script (AIS)

The AIS format is a format of storing the boot image which can be interpreted by the D800K001 bootloader. The AISgen tool converts a COFF-file for the DSP into AIS format (either a binary or a header file). Therefore several settings can be configured in the GUI of this tool:

• Boot mode
• Clock source
• PLL configuration
• EMIF configuration
• "Standard" or compressed AIS
• …

Please refer to the application report [2] for a detailed description the AISgen tool and the required steps to generate AIS files.

Note: AIS files do not perform all of the configuration steps that a GEL file typically handles during development. Notably, AIS will not setup the Pin Multiplexing Control Register (PINMUX) and the Power and Sleep Controller Register (PSC) for any peripheral devices your DSP application uses. Be sure to add the necessary configuration steps to your application code before generating the AIS file.

SPI Slave boot procedure

About the AIS interpreter on the Host

When booting from an external host processor, the host acts as the communication master, and the bootloader acts as the slave. Since the bootloader doesn’t have direct access to the AIS, the host processor must transfer it to the bootloader through a well-defined protocol explained in the following sections. An AIS interpreter is required on the host processor to control this transfer.

The AIS interpreter on the host processor is responsible for transferring the AIS to the bootloader. Therefore, the host has to understand the transfer protocol and implement the required handshake mechanism. It is important to establish a reliable link between the host and the bootloader before starting a serial boot load using the AIS. Once this link is established, the AIS can be transferred to the bootloader. This complete synchronization and transmission process is divided into three states:

• Start-word synchronization (SWS),
• Ping Op-code synchronization (POS) and
• Op-code synchronization (OS).

Start-word synchronization (SWS)

After power ON reset (POR), the bootloader takes some time to initialize and configure the boot peripheral. Similarly, the host also takes its own time to initialize and prepare to boot the device. A SWS mechanism is used to synchronize the device and host after POR. To achieve SWS, the host repeatedly sends transmit-start-word (XMT_START) to the device until it receives the receive-start-word (RECV_START) from the bootloader.

For the SPI slave modes, the bootloader operates the SPI peripheral in 16-bit mode, so that both start words are 16-bit values:

• XMT_START = 0x5853
• RECV_START = 0x5253

Note: While XMT_START and RECV START are 16-bit in SPI Slave mode, all other data including op-codes are 32 bit, and all 32 bits need to be transmitted to the bootloader regardless of the boot mode.

Ping Op-code synchronization (POS)

The POS is used to further ensure that the serial link between the host and the device is reliable for exchanging boot information.

After successful SWS:

• The host sends the PING_DEVICE (0x5853590B) op-code to the bootloader and receives the RECV_PING_DEVICE (0x5253590B) as acknowledgment from the bootloader.
• The host sends an arbitrary 32-bit number (N) to the bootloader and gets back the same number (N) from the bootloader.
• The host counts from 1 to N, sending each number to the bootloader and receiving the same number in response. Each number sent or received is a 32-bit value.

Note: All multi-word values transmitted by the host should be sent in little-endian order. For instance, the Ping opcode (0x5853590B) is sent as 0x590B, 0x5853 in 16-bit mode. The same applies to responses received from the bootloader.

The count (N) is selected by the host and should be appropriate to assure successful communication between the device and host. The recommended value of N is 2.

After the successful execution of POS, the host starts reading AIS commands (magic number is checked and ignored by the host) from its source and starts booting the device.

Op-code synchronization (OS)

As the bootloader may take an indeterminate amount of time to execute an AIS command, a handshake mechanism is needed between the host and the bootloader before the host can send any command to the bootloader. The following opcode synchronization method is used for this purpose:

All opcodes that are transmitted by the host to the bootloader are of the form 0x585359##, where ## varies for individual opcodes. The bootloader acknowledges each opcode with a corresponding RECV opcode. The RECV opcodes are generated from the original opcodes by changing the most significant byte to 0x52. Thus, they are of the form 0x525359##. Not getting a correct response (RECV opcode) from the bootloader indicates that the bootloader is busy executing the previous command. The host should continue sending the opcode until it is successfully acknowledged by the bootloader. After the correct RECV opcode was received by the host, it has to transmit the arguments belonging to this opcode. The arguments only have to be transmitted one by one, i.e. the bootloader is not sending these data back to the host.

Note: Before the PLL is configured it is bypassed, i.e. the device is operating at the oscillator frequency. Because of that it is required to insert a delay between the transmission/reception of each 16-bit block, to ensure that the DSP can receive and process the data correctly (e.g. for-loop counting up to 0x3FF @ 160MHz). After the PLL was configured (frequency as selected in the AISgen tool) this delay could either be completely removed or at least reduced tremendously (e.g. for-loop counting up to 0x3 @ 160MHz), depending on the baudrate and the configured PLL frequency.

Boot Requirements, Hardware Setup and Default Settings

• Bootloader Memory Usage: The bootloader uses 16 KB of DSP L2 RAM starting from 0x11800000 for multiple purposes. This memory should not be used by any initialized section of the user application.

• Decompression Heap: When the compression option is used, the bootloader uses up to 64 KB of DSP L2 RAM starting from 0x11830000 to allocate heap for the decompression algorithms. This memory should not be used by any initialized section of the user application. The AISgen tool displays the actually required amount of memory for these algorithms for a particular COFF-file.

• Boot mode selection: To configure the bootloader in the correct boot mode, the BOOT[x] pins have to be configured as shown in the table below:

Boot mode	BOOT[7]	BOOT[2]	BOOT[1]	BOOT[0]	BOOT[3]
SPI0 Slave	1	0	0	1	0
SPI1 Slave	1	0	0	1	1

• Hardware configuration: In addition to the SPICLK, SPISIMO and SPISOMI signals, you also have to connect the SPICS signal (chip select) from the host and the DSP.

• SPICLK phase and polarity configuration: In the SPI boot mode, the received data is sampled at the rising edge of the clock and the data to be transmitted on the falling edge of the clock:

• SPI Baudrate: After power on reset the device is running at its default PLL and clock configuration. Hence the maximum supported baudrate is 2 MBaud (recommended to start development with a slower baudrate of e.g. 1MBaud). When the PLL is configured, typically after the first 10 transmitted AIS words during opcode synchronization, the baudrate could be increased depending on the PLL settings and the SPI Master and Slave timings.

References

• http://www-s.ti.com/sc/techlit/sprab04