C6678 SPI Flash boot failure

Aguilera

C6678 SPI Flash boot failure [Copy link]

The 6678 on the XX board uses I2C to connect to other hosts for booting. However, the Nor Flash booting method is reserved as a backup booting method during design, so the SPI Flash booting method needs to be debugged.

The 6678 supports multiple boot modes, which are described in the Bootloader for the C66x DSP User Guide (sprugy5b). Different boot modes are configured by the state of the boot mode pins at power-on. The XX board uses a DIP switch configuration during the development phase.

According to the manual, you need to generate a boot image and burn it into Nor Flash. The boot image in SPI Flash mode is divided into two parts, one is the boot parameter table, and the other is the boot table. The boot table is generated by gradually converting the format of the .out file generated by compilation through some tools provided by TI. The boot parameter table is different in each boot mode and can be filled in manually byte by byte.

First, I made a simple flashing program, downloaded it with the emulator and ran it successfully, then used the tool to convert the startup table. Finally, I needed to add the startup parameter table manually.
The example provided by TI has a startup image for I2C EEPROM, but no SPI image. The startup table format of the two is the same, but the startup parameter table format is slightly different. I referred to the manual and modified it according to I2C to generate an image, burned it in, modified the dial code, and found that the light was not on after powering on.

At this time, I went back to the manual and analyzed it carefully. I spent two days but still couldn't find the problem. I couldn't find the relevant information on the Internet. Later, I reorganized my thoughts and sorted out the CPU startup flow chart according to the manual, and then prepared to check step by step.

First, after power-on, sample the pin to determine the startup mode. Use a multimeter to measure the dial level and find no problems. Use an oscilloscope to check the CPU clock output pin and find an output signal, indicating that the CPU is working normally.
Then read the Flash data. Use an oscilloscope to look at the Flash waveform. There are output and input signals, which confirms that the CPU has entered the SPI startup branch. But the signal disappears after about a few dozen bytes, while under normal circumstances there should be hundreds of bytes. There is obviously a problem here, but the reason is unknown.
Since the CPU is executing instructions in the BootROM during the startup process, it is not convenient to track. At this time, analysis and debugging are in trouble.

After a while, the technical support on the TI Chinese forum provided the source code of the Bootloader. After spending several days reading the source code and understanding the general steps of the boot process, I plugged in the emulator and executed the assembly instructions step by step against the source code. It took another day to figure out some important details. I spent several more days looking for the problem but to no avail. Finally, during a debugging session, I suddenly discovered that the definition of the boot parameter table in the source code was inconsistent with that in the documentation.

The definition of the startup parameter table in the source code is:

typedef struct boot_params_spi_s
{
/* common portion of the Boot parameters */
UINT16 length;
UINT16 checksum; UINT16
boot_mode;
UINT16 portNum;
UINT16 swPllCfg_msw
;

UINT16 options;

UINT16 addrWidth; /* 16 or 24 are the only valid values */
UINT16 nPins; /* 4 or 5 pins are the only valid values */
UINT16 csel; /* only values 0b10 (cs0 low) or 0b01 (cs1 low) are valid */
UINT16 mode; /* Clock phase/polarity. These are the standard SPI modes 0-3 */
UINT16 c2tdelay; /* Setup time between chip select assert and the transaction */

UINT16 cpuFreqMhz; /* Speed the CPU is running after PLL configuration */
UINT16 busFreqMhz; /* The speed of the SPI bus, the megahertz portion */
UINT16 busFreqKhz; /* The KHz portion of the bus frequency. A frequency of 1.5 MHz would have the value 5 here */

UINT16 read_addr_msw; /* The base address to read from the SPI, upper 16 bits */
UINT16 read_addr_lsw; /* The base address to read from the SPI, lower 16 bits */

UINT16 next_csel; /* The next chip select to use if in boot config mode, when the config is complete */
UINT16 next_read_addr_msw; /* The next read address to use if in boot config mode */
UINT16 next_read_addr_lsw; /* The next read address to use if in boot config mode */

} BOOT_PARAMS_SPI_T;

The description of the parameter table in the document is:

The two are inconsistent from byte 14. Modify the boot parameter table in our image according to the code description, re-burn it into Flash, power on, and the light will turn on! The problem is solved.

Here I want to complain about TI's support for 6678. When we started using it in early 2003, 6678 was still a new thing, and it was not widely used in the industry, but TI was vigorously promoting it. We were the first batch of people to try it out, and we also participated in technical training in Beijing. As a result, during the one-year development process, we found several document errors, library bugs, and sample code errors, and we couldn't find any information on the Internet. The whole development process was full of twists and turns, which really trained people. Half a year after our driver gradually stabilized, there was a large increase in posts about 6678 in the forum, and a large number of projects using 6678 appeared in the resumes of graduates. I haven't been to TI's forum for a long time. I don't know if TI will return to pay attention to these problems and provide a fixed version when user feedback explodes.
Now in the process of our research on the new platform, we found that TI's KII series is also facing the same situation as three years ago. The leader proposed not to pursue new things too early. I think it will be much smoother to explore KII again in one or two years.