I'm having trouble booting from a SD card on the C5505. I've obtained the C55BootImageV2.exe program and associated documentation, and I have had some success getting it to work on the ezDSP C5515 board in NOR flash. On the evaluation board, I was able to boot both encrypted and unencrypted from NOR flash. When encrypting, I was able to use various keys (all 0’s, 10…01, all 0xA’s, etc.) and it still booted.(It’s not possible to boot from SD on that evaluation board since the SD card is on the MMC/SD1 port instead of SD0, but NOR flash booting worked.)
We wanted to replicate this on our custom C5505 board, and then also extend our success to boot from the microSD card (which is on MMC/SD0).
On our C5505 board, we can boot from NOR flash using the following command to generate the bin file: "C:\Tools\TI\ccsv5\tools\compiler\c5500\bin\hex55.exe" -boot -v5505 -b -fill ffh program.out -o program.bin
However, when we use the C55BootImageV2 to create an unencrypted (or encrypted) image and put it in NOR flash, our processor fails to boot.(We then reverified that we could still boot from our hex55 generated bin.)
What’s different in these scenarios? It seems like the only difference is the flags passed to hex55.exe. I don’t think there is any way to specify additional flags to the C55BootImageV2.exe.
What's going wrong?
Additional info: We're not using SARAM31:SARAM31 (RX): origin = 0x04E000, length = 0x002000 /* SARAM31 reserved for Boot Loader */
Also, can you verify that this wiki is wrong? (As of Last Modified date: 26 January 2012) All the other documentation says that you cannot boot using a non-encrypted boot image using a SD card, but the above wiki doesn't even mention secure boot images.
Most resources say something like the following:“In order to ensure the code cannot be accessed and read outside of the system, only encrypted images can be boot from MMC/SD and USB. Both encrypted and non-encrypted images can boot from NAND, NOR, 16-bit SPI EEPROM, and I2C EEPROM.”
So, I bluewired the C5515 EZDSP board so the lines of MMC/SD0 are connected to MMC/SD1 (by soldering wires to the edge connector). I also unpopulated R74,75,76,77 to disconnect the I2S device.
I can now see the SD clock toggle on the microSD card, but the boot5505.bin image does not boot.
Does the bootloader properly pin-mux the SD1 port (to high-Z GPIO)? If not, that might interfere with the booting since some of the SD/MMC lines might be driven by multiple lines of the C55x (since the MMC/SD0 and MMC/SD1 lines are shorted together pairwise by bluewires).
If the MMC/SD1 pins are properly muxed to Hi-Z GPIO by the ROM bootloader, then I don't know what's wrong.
I'm assuming my boot5505.bin image is correct since the following is true:1) It is encrypted but not "Bound to Device"2) It works in NOR Flash
Sorry for your trouble. Lets figure out what is going on...
I understand that your C5515 eZdsp... NOR Boot unsecure boot works hex55 worked - CONFIRMED C55BootImageV2.exe worked (unsecure) - CONFIRMED secure boot works (C55BootImageV2) - CONFIRMED
I understand that your custom C5505 board... NOR Boot HEX55 unsecure boot works C55BootImage unsecure boot FAILS secure boot FAILS SD Boot Have you tried booting from SD?
Additionally, I have tested the C5515 EVM for boot...
C5515 EVM NOR HEX55 unsecure boot PASSES - hex55 C55BootImageV2 unsecure boot PASSES secure boot PASSES SD C55BootImageV2 unsecure boot FAILS (EXPECTED) secure boot PASSES
Can you use the C5515 EVM as your development board?
Check for valid Boot Signatures in each .bin file with a Hex Editor? First 16-bits of .bin file Unsecure: 0x09AA Secure: 0x09A4, 0x09A5, 0x09A6
Can you tell me the exact part number of C5505 on custom board?
Have you formatted SD card with FAT16/32?
Are all boot sources with higher precedence erased? (NOR erased when booting from SD) - Clear first two bytes (boot signature)
dpryan Also, can you verify that this wiki is wrong? (As of Last Modified date: 26 January 2012) All the other documentation says that you cannot boot using a non-encrypted boot image using a SD card, but the above wiki doesn't even mention secure boot images.
The C5535 DSP family can boot non-secure .bin files over SD - I will clarify that wiki to say so. It is the only device of the C5505/C5515/C5535 devices to support non-secure boot from SD.
dpryanSo, I bluewired the C5515 EZDSP board so the lines of MMC/SD0 are connected to MMC/SD1... Does the bootloader properly pin-mux the SD1 port (to high-Z GPIO)?
No, during the boot from SD phase of the bootloader, both serial ports are pin-muxed for the SD interface... Serial Port 0 for SD0 and Serial Port 1 for SD1. So I could expect possible contention in the case where both SD interfaces are shorted together. You might try to cut the PCB traces from microSD card slot to SD0 to remove the shorting - THIS WILL VOID YOUR BOARD'S WARRANTY
I have also attached some test .out and .bin files. This program simply toggles LEDs (check the XF LED). Try these files with your board and let us know the results. If these bin files boot correctly, then there may be something strange with your program...
I dont understand how unsecure .bin files can boot from the NOR flash on your custom C5505 board, but the secure .bin files cannot...
What NOR flash are you using? What chip select is it connected to?
Hope this helps,Mark
---------------------------------------------------------------------------------------------------------Please click the Verify Answer button on this post if it answers your question.
Also see our C5000 Wiki---------------------------------------------------------------------------------------------------------
Thanks for your detailed response.
eZDSP C5515 ModulePresumably everything is working fine with the eZDSP C5515 module with the EZDSP_Sample project. As you mentioned, I can boot from NOR encrypted and unencrypted. In a couple days, I'll be able try booting from SD by grabbing a new eZDSP module and attaching an external microSD to the SD0 port (and again unpopulating R74,75,76,77 of the I2S device). This will avoid the contention caused by attaching SD0 and SD1 together. I think it is very likely that it will work.(Bin file generated by C55BootImageV2 was 27,014 bytes for the EZDSP_Sample project.)
Custom C5505 BoardThe C5505 chip is TMS320C5505AZCHA12.The NOR flash chip is Spansion S29GL064N11FFIV10 connected to CS2. (4MBytes x 2 Banks (via GPIO control))Our C5505 board is connected quite differently compared to the eZDSP module, so rather than use the same EZDSP_Sample project (which would produce no visible output... no easy way to see if it is working), I initially tried our much more complex application project running DSP/BIOS. (Bin file generated by C55BootImageV2 is 219,064 bytes). This was the project that worked out of NOR flash when using the hex55 tool, but not the C55BootImage tool. It also didn't work out of microSD.
After some more experimenting today, I was able to get a different project to boot from microSD on our custom 5505 board and generate some output using our external CS5 UART validating that it worked (booted from microSD). That bin file generated by C55BootImageV2 was 136,414 bytes for this project. I didn't try on NOR flash, but presumably it works there, too.
Since this worked, you can guess the answers to most of your questions: (Formatted with FAT32, higher boot sources were erased, boot signatures were 0x09A5)
So, it seems to core of the issue that I'm having now is why boot images generated by the hex55 tool work while the C55BootImage doesn't work for certain projects. Maybe it has to do with the project size or the way code is placed?
As you put it: HEX55 unsecure boot works C55BootImage unsecure boot FAILSI think if we can figure out how to fix that problem, I'm pretty sure the secure images will boot from microSD.
Thanks again for your help.
P.S. I'll let you know the results with your sample project once I try it out.Also, I have a C5505 EVM (not C5515) that I could try if needed.
I just took a closer look at the map file for our DSP/BIOS project.
I forgot to mention earlier that external CS3 SRAM (CY62167EV18LL-55BVXI) is being used by our DSP/BIOS project on our custom board.However, I don't think that should cause a difference between the hex55 tool and the C55BootImage tool.
SARAM is split to avoid 64kword boundaries. (Although we use huge memory model, so it shouldn't really matter.)
name origin length used unused attr fill (bytes) (bytes) (bytes) (bytes)---------------------- -------- --------- -------- -------- ---- -------- VECT 00000100 00000100 00000100 00000000 RWIX DARAM 00000200 0000fe00 0000fdf0 00000010 RWIX SARAM_1 00010000 00010000 0000ffcd 00000033 RWIX SARAM_2 00020000 00020000 0001fff5 0000000b RWIX SARAM_3 00040000 0000e000 0000e000 00000000 RWIX SARAM31 0004e000 00002000 00000000 00002000 RWIX EMIF_CS3 00c00000 00200000 001028ea 000fd716 RWIX
Using your programs:The run time of the program (and the speed at which the leds toggled) varied according to the boot method.It ran quickly out of RAM, but slowly when booting from flash. I would have thought the execution time would be approximately the same since the bootloader copies from NOR flash to RAM before executing the program.Quick = Run time ~3 secondsSlow = Run time ~25 secondseZDSP Module:RAM: Worked. led.out (Quick ~3 second run).NOR: Worked. led_C55BootImage_secure.bin (Slow). Worked. led_C55BootImage_unsecure.bin (Slow). Worked. led_hex55_my_flags.bin (Slow). Worked. led_hex55_your_flags.bin (Slow).microSD: (Will be tested on Thursday)
Custom C5505:RAM: Worked. led.out (Quick ~3 second run).NOR: Worked. boot5505.bin (aka led_C55BootImage_secure.bin) (Slow)microSD: Worked. boot5505.bin (aka led_C55BootImage_secure.bin) (Slow)
Edit: I didn't think the secure boot image worked on the C55x custom board when I tested yesterday, but I just tried it again today and it seemed to work out of NOR and microSD. (I verified that it boots with microSD but doesn't boot with the microSD card ejected, which sorta proves that the NOR flash was cleared for this microSD test.)Edit2: The difference between fast and slow is probably my gel script that gets run before running the .out files in ram.
Has anyone tested booting a secure boot image that was linked using the RAM autoinitialization model instead of the ROM?
This problem was solved by Jrvanho. I'm posting the resolution here in case other people run into the same issue.
Can someone from TI verify that the RAM linker command doesn't work properly? If so, is it possible to get this fixed because of the silicon bug?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.