TI中文支持网Hi team，
目前我们正在使用TMS320C553X进行开发，程序会稍微有点大，希望能够放在外置的SPI flash中，型号位SST25VF010A-33-4C-SAE，在使用Programmer将程序烧录完成后，DSP没有从Flash启动程序，通过查询SPI总线发现在DSP上电的过程中没有发现SPI总线上有SCK和data的信号，只有CS0#的片选被拉低了大约300ms，能不能给些提示。Flash方面HOLD#和WP#型号都上到到高电平。
另外在使用Progammer烧录的时候会提示输入偏移地址，暂时我设置的都是0x00.不知道这个会不会影响启动。
感谢。
Shine：
请看一下使用的spi flash是否支持read command (03h opcode)读命令？
,
Wang Jiping：
Hi Shine，
非常感谢你的帮助。
首先这颗Flash应该是支持03h的读命令的。
另外让我比较困惑的是在DSP上电的过程中没有发现SPI总线有信号，我尝试用CS0#和SCK来抓取信号但是都不成功。
,
Shine：
有可能是boot image转换的不对，bootloader识别不到，就没进到SPI boot模式。请看一下是否按照下面bootloader文档生成的。
3 Boot Images
www.ti.com/…/sprabl7d.pdf
,
Wang Jiping：
Hi Shine,非常感谢你的帮助。在我做尝试修改boot image之前，麻烦帮助我整理下这颗DSP从Flash 启动的顺序。在我的理解中，DSP的bootloader应该首先尝试从onchip的ROM中启动，如果失败，就先使用SPI接口尝试读取挂在CS0#上的Flash，这个时候bootloader才知道能不能从Flash中启动。如果不读取flash中的任何信息，bootloader怎么知道能不能从Flash中启动。另外我应该不需要/也不能修改本身DSP得bootloader吧。只需要把正确的bin file program到Flash ROM就可以了是吧。感谢。
,
Shine：
DSP复位后，会自动从onchip的ROM中启动，启动顺序是固定的，可以参考数据手册的6.4 Boot Modes启动过程。
The DSP supports the following boot modes in the following device order: SPI 16-bit EEPROM, SPI 24-bit Flash, I2C EEPROM, and eMMC boot partition, eMMC, SD, or SDHC card. The boot mode is determined by checking for a valid boot signature on each supported boot device. The first boot device with a valid boot signature will be used to load and execute the user code. If none of the supported boot devices have a valid boot signature, the bootloader goes into an endless loop checking the UART or USB boot mode and the device must be reset to search for another valid boot image in the supported boot modes.
www.ti.com/…/tms320c5535.pdf是的，ROM里的bootloader，用户是不能修改的，只需把正确的bin文件烧写到flash就可以了。
,
Wang Jiping：
非常感谢你的帮助。暂时我还没有成功的从flash romboot起来。
我查看了DSP和Flash ROM的datasheet，感觉这颗Flash应该是满足DSP的boot rom的要求的。
.
我对时序也进行了测试，发现DSP也是可以尝试从Flash中读取数据，而Flash好像也是有回复data的，但是在1个byte完了之后，片选很快就被拉高了，感觉EA这个data不是DSP想要的。
1.我现在是按照3.1.1.1的方法来建立这个boot image的。没有用到3.1.1.2的方法，不知道这样对于对。
2.我是使用CCS 6中build里的C5500这个tool来生成boot的bin file的。能不能帮忙看下这些设置是不是足够了。我注意到默认的生成的文件名的后缀是.HEX，我手动改成了.bin。
3.如果EA这个data不是DSP期望得到的，那DSP得到得到的1st byte应该是什么。
感谢。
,
Shine：
boot image的第一个word是boot signature，请看一下是不是0x09AA。
,
Wang Jiping：
非常感谢。我觉得我已经非常接近成功解决这个问题了。
我尝试将在CCS目录下的hex55这个工具copy到程序的目录下，然后使用这个工具生成了一个my_app.bin的文件。
这个文件的第一个word就是0x09AA。上电之后也的确发现DSP大量的从CS0#中读取数据。
目前的问题是，我为了简单的确认DSP能不能boot起来，在代码中加入了关于某些GPIO管脚的状态的翻转，在online debug的时候可以用示波器观察到这些管脚都会翻转，但是把这个.bin的image烧录到flash中却无法观察到这个引脚的翻转。整个DSP的功能好像也没有工作。
另外使用这个工具得到的.bin文件的大小远远小于.OUT文件，我的.out文件大约有300kB，而.bin文件只有62kB，这个算不算正常。
感谢。
,
Shine：
建议先写个最简单的GPIO翻转的程序进行调试，看一下流程步骤有没有问题。.out文件里包含调试信息，实际文件大小可以通过查看.map文件。 如果烧录后boot不起来，可以用仿真器连上板子去跟一下boot过程，看是程序没有boot进来还是boot进来后没有正确运行起来？ 连上仿真器，板子上电，打开CCS, load symbols，然后可以设置硬件断点跟踪boot过程。 "Load Symbols" instead of "Load Program" When debugging an application from flash, you want to let the application boot in its normal manner. If you select "load program" in CCS then you are overwriting the application that loaded from flash and not debugging the code as it runs normally. You should instead do "load symbols" in CCS and then select your .out file. This will allow you to debug your code using variable/function names without overwriting the code that boots from the flash. CCS 3.3: Go to File -> Load Symbols -> Load Symbols Only CCS 4.x: Right-click on the project and select Debug Options. On the "Debugger" tab choose "Load Symbols" instead of "Load Program" CCS 5.x: In the "Debug View" tab choose "Run"–> "Load" –> "Load Symbols" 下面是常见的3个boot问题。 Common Mistakes in Boot Image User Code Relying on GEL File for initialization A frequent issue is that the user code works fine in CCS environment but fails to work after converted to boot image. This is most likely because the user code relies on a GEL file in the CCS environment to initialize and setup PLL. This is easily corrected by not using GEL in CCS environment, but instead including all the necessary initialization steps in the user code. It is a good practice to re-initialize everything you need from within your bootloaded user code. Example code to program PLL in user code: // Bypass the PLL as the system clock source asm(" *port(#0x1C1F) = #0x0 "); //Clock Configuration MSW reg // program PLL to 100MHz with CLK_SEL = 0 asm(" *port(#0x1c20) = #0x8BE8 "); //PLL Control 1 reg asm(" *port(#0x1c21) = #0x8000 "); //PLL Control 2 reg asm(" *port(#0x1c22) = #0x0806 "); //PLL Control 3 reg asm(" *port(#0x1C23) = #0x0000 "); //PLL Control 4 reg // wait at least 4 milli sec for PLL to lock asm(" repeat(0xC350) "); asm(" nop ") asm(" *port(#0x1c1F) = #0x0001 "); // Clock configuration MSW reg Loading code into SARAM31 Another common mistake is allocating program code to SARAM31 memory. The bootloader writes to SARAM31 (CPU byte address 0x4E000 – 0x4FFFF) thus any user code residing in SARAM31 will be corrupted. Do not use SARAM31 if you intend to convert this code to a boot image. Once the bootloader has finished loading the program into RAM, SARAM31 can be used. How to tell whether SARAM31 is used? Refer to the .cmd file in CCS project folder. The usable SARAM location is defined in the memory section. SARAM is resided in CPU byte address 0x010000 to 0x04FFFF, refer to memory block in data manual, and is partitioned into 32 blocks. This is an example of SARAM31 is used. SARAM is defined as starting from 0x010000 with a lenght of 0x040000 which igoes all the way to 0x050000 which includes SARAM31 (CPU byte address 0x4E000 – 0x4FFFF) MEMORY { PAGE 0: VEC(RX) : origin = 0000100h length = 000100h SARAM(RW) : origin = 0010000h length = 040000h } Ports idled by bootloader By the time the bootloader releases control to the user code, all peripheral clocks will be off and all domains in the ICR, except the CPU domain, will be idled. This means that DMA and USB CDMA will not work until the MPORT is enabled. The HWAFFT will not work until HWA port is enabled. After the boot process is complete, the user is responsible for enabling and programming the required clock configuration for the DSP. This is the example code to enable the MPORT and disable the FFT HWA. // enable the MPORT and disable HWA *(volatile ioport Uint16 *)0x0001 = 0x020E; asm(" idle");
,
Wang Jiping：
Hi
非常感谢。
关于gel file的问题，当我把gel file从script中去掉之后，使用debug仍然可以正常的运行程序，这样是不是可以被认为不是gel file的问题。
接下去是mem map，我查看了cmd文件，发现应该也是没有使用saram31.
PAGE 0: MMR(RWIX) : o = 0000000h,l = 0000c0h VEC(RWX) : o = 0000100h l = 000100h STACK : o = 0000200h l = 004000h CODE_SPACE : o = 0004200h l = 01F000h
但是不知道在cmd文件下面的section中的写法有没有什么关系，比如vector的指向。
感谢。
,
Shine：
1. 可以在ccs->target configuration file里把gel去掉，这样在lauch CCS时不会加载GEL文件，如果debug可以的话，和GEL文件没有关系了。
2. 没有用的话，就不是占用saram31的问题。
建议用仿真器跟一下boot的过程。
,
Wang Jiping：
非常感谢。
有没有什么文档或者链接可以告知如果通过debugger调试boot的过程，因为一般我只用他来调试软件。
,
Shine：
连上仿真器，板子上电，打开CCS, load symbols，然后可以设置硬件断点跟踪boot过程。
"Load Symbols" instead of "Load Program"
When debugging an application from flash, you want to let the application boot in its normal manner. If you select "load program" in CCS then you are overwriting the application that loaded from flash and not debugging the code as it runs normally. You should instead do "load symbols" in CCS and then select your .out file. This will allow you to debug your code using variable/function names without overwriting the code that boots from the flash.
CCS 3.3: Go to File -> Load Symbols -> Load Symbols Only
CCS 4.x: Right-click on the project and select Debug Options. On the "Debugger" tab choose "Load Symbols" instead of "Load Program"
CCS 5.x: In the "Debug View" tab choose "Run"–> "Load" –> "Load Symbols"
