why boot fail? the difference between *.hex and *.ais format.

yan jie,

Welcome to the TI E2E Forum. I hope you will find answers and great library of information from past threads (use the red Search box or just browse) and from Community support to your question here and in the future. I am sure you are already aware of the other resources available to you, but I would like to list here that TI.com is the place to find all the available documentation and the TI Wiki Pages have a ton of useful articles for helping you use the TI Processors and TI Tools.

Which boot mode did you use with the non-BIOS project? It is not obvious whether you used the same mode for both.

The app note "Using the TMS320DM643x Bootloader" SPRAAG0 describes how to generate the boot images. Do you have questions about any particular sections of that app note? I would recommend it as the source for the answers to your questions, so perhaps there are parts of it that are not clear for your case.

Are you using an EVM or your own custom board?

Do you have emulation running with this board?

Which version of CCS 3.3 do you have installed? Go to Help->About to get this.

First,Thank you for your help.

I am using EVM of SEED co.. I have emulations running with this board,They are OK.I have read"Using the TMS320DM643x Bootloader" and "Creating a Second-Level Bootloader for FLASH Bootloading on TMS320C6000 Platform With Code Composer Studio".The Bootmode of my two applications are EMIF from ROM Fastboot with AIS.  I have noted that user dont need to programm a COPY TABLE if  the app codes are burned  to flash with .hex format . Do I need to programm a boot.asm with COPY TALBE, in order to realize the data are removed from flash into RAM afer reset. Do I need to creat a intterupt vector file of vector.asm? Watchdog must be closed,how can I operare the timer2 in DSP/BIOS?

I creat a new memory named BOOTLOADER,whose space is Data(some files say its space cannot be code/data ).Then I program a section named .bootld into BOOTLOADER.Is there other operations needed to do? The version of my CCS is CCS_3.3.81.6 

I am eager for your help.

Yan Jie,

The documents you have listed explain the bootloader's operation much better than I can explain it in this forum. If there is a particular part that is unclear, please point me to the page, section, and even the line, as needed, so I can help to make any portion more clear.

Do you need a second-level bootloader for either of your applications? I expect the answer is "no" since you can have a very large FLASH device on the EMIF bus, and because you have not mentioned any secondary boot source.

yan jie said:

I have noted that user don't need to program a COPY TABLE if  the app codes are burned  to flash with .hex format . Do I need to program a boot.asm with COPY TABLE, in order to realize the data are removed from flash into RAM afer reset?

I do not know of a connection between the copy_table and the bootloader with AIS. So I think the answer is "no", but I am not sure why you are asking this or what exactly you are asking about.

RandyP said:

Are you using an EVM or your own custom board?

The rest of your questions should be covered in the "Using the TMS320DM643x Bootloader" document, or else I do not understand what you want to know. I may need more information to help you. And if you have questions that are related to the use of software tools like DSP/BIOS, you may want to post separate questions to the Code Composer forum.

Sorry that I am not being much help.

Regards,
RandyP

Tank you very much!

I need your help for another questions .In the document "Using the TMS320DM643x Bootloader (Rev. C)",a note in the Table 3 said "For all boot modes that default to DSPBOOTADDR = 0x0010 0000,", and In document "TMS320DM6437 Digital Media Processor", Table 3-11 said  "The default value of the DSPBOOTADDR depends on the boot mode selected.The DSPBOOTADDR defaults to 0x00100000 when the Internal Bootloader ROM is used.or The DSPBOOTADDR defaults to 0x42000000 when EMIFA CS2 Space is used." Table 2-3 means the size of Boot ROM is 64K.So I think if my code is lager than 64K,I must creat second-level bootloader.Do I have the point?

In the  chapter 2.3.1.2  of "Creating a Second-Level Bootloader for FLASH Bootloading on TMS320C6000 Platform With Code Composer Studio",it is said "The hex conversion utility (hex6x v4.3.3 and later) provided with Code Composer Studio provides a more convenient method for creating the section copy table by automatically building the copy table when the appropriate options are specified in the hex conversion utility command file".  In my project ,I converted the .out to AIS with the AIS utility provided by TI, does it also automatically  creat a copy table like Hex utility?

I don't have custom board ,I had bought the EVM DM6437 board where my projected run with.

I am eager for your help.

yan jie said:

I must create second-level bootloader.Do I have the point?

No, you do not need to create a second-level bootloader. You only need to go through the AIS flow to generate the file to program your EMIF Flash with your entire application. The ROM size is not relevant to your application's size.

The EVM may come with examples that show how to program an application into an on-board Flash. This example, and more examination of the Using the Bootloader document will help you understand the boot flow.

Regards,
RandyP

Thank you very much!!!

I think I should try it again.

Wish you good luck!!

Please keep us posted on your progress or problems. And please post a follow-up with your successes to help the next engineer needing to go through this process.

RandyP

OK.

After my code is burn into flash,I had debug the disassamble code step by step.And I found it run into a limitless loop. The code that are operated  repeatinglly  are shown below:

802AE200 04C000C6            LDH.D2T2      *-B16[0],B9
802AE204 004C2009            EXTU.S1       A19,1,0,A0
802AE208 10210005 ||         .word         0x10210005
802AE20C 00060008 ||         EXTU.S1       A1,16,0,A0
802AE210 20000090     [ B0]  B.S1          0x802AE204 (PC+4 = 0x802ae204)

I haven't know why,I will go on trying.

This is invalid code, so your program is not being loaded correctly or is not being executed from the correct place. There should never be a .word in the middle of an execute packet and the two EXTU instructions are not valid within the same execution packet.

If you can, try to use a hardware program-execution breakpoint to stop the DSP at _c_int0 or even better at wherever the entry point is supposed to be. If you can do that, you can look at this code immediately after the boot code has completed and before anything in the application has executed. If it looks like what you posted above, then you know that the bootload process was wrong. If it looks different (and correct) then something in your application may be corrupting the memory.

Keep trying things and let us know.

Regards,
RandyP

Thanks.

I debug with hardware breakpoint at _c_int00.Then it run into a limitless loop ,the code is shown below.The code is used to configure the EMIF in Ais utility.Does it mean the boot is successful?I don't know why the other code cann't  be run .And the codes are run in flash memory,why it doesn't be moved into RAM?

the limitless loop is between 0x42000000 and the green arrow in the picture.

This is invalid code that is shown here, too. Does this match the content of the *.hex or *.bin file that you have written to the Flash?

You mentioned earlier that you were using the bootmode "EMIF from ROM Fastboot with AIS". The operation you are observing implies that you are using "EMIFA ROM Direct Boot", so you should verify your boot configuration pin values when RESET or POR is released.

My guess is that the FASTBOOT pin is not at the correct state for the boot mode you want to use.

RandyP said:

This is invalid code that is shown here, too. Does this match the content of the *.hex or *.bin file that you have written to the Flash?

Yes,They are the same.

I converted my .out file into .asm file with the AIS utility .

Then I checked the contents in flash and the contents in my .asm file.They are the same.

RandyP said:

You mentioned earlier that you were using the bootmode "EMIF from ROM Fastboot with AIS". The operation you are observing implies that you are using "EMIFA ROM Direct Boot", so you should verify your boot configuration pin values when RESET or POR is released.

My guess is that the FASTBOOT pin is not at the correct state for the boot mode you want to use.

 I think you are right .Then I have checked my evm board.And I read the BOOTCFG register with menu"【view \ memory】".The address of BOOTCFG register  is 0x01c40014,the value is 0x00184104.It means BOOTCFG [3:0]=Bootmod[3:0]=0100,  BOOTCFG [19]=FASTBOOT=1, and BOOTCFG [10:8]=001. Am I right? But ,as what you said,it seems to run from the BootAddr is 0x42000000,not from the 0x0010 0000. What I read from BOOTCFG register  does not accord with what BOOTCFG pins is designed on the board ! What  may be the reason？

By the way,Wish you merry Christmas Eve!

yan jie,

The BOOTCFG contents are correct for the boot mode you intend, Fast EMIFA w/ AIS, so your pins are set correctly and the BOOTCFG register is set the way you way you want it to be set. This leads me to believe that the ROM code may be started as expected and the DSP is reaching the EMIFA CE2 address space at 0x42000000 later because of a different configuration error.

If you were able to set a hardware breakpoint at 0x42000000, try setting one at 0x00100000 also (or only at 0x00100000, if only one hardware breakpoint is available). It would be good to find out if the ROM code is executing. Another test you could do is to stop at the 0x42000000 breakpoint and check if some of the initialization was done correctly. Check the registers that you intended to initialize from the AIS initialization values, and see if they have the correct new values or the default values from a reset.

My thought now is that the AIS execution may be happening correctly, but then the entry point is set incorrectly to send you to 0x42000000. This would simply be a matter of changing the entry point to the run-time address _c_int00.

Please let me know if any of this helps, and what you learn from some of these tests.

Regards,
RandyP

[Thank you for the Christmas wishes. I too hope all is good for you, a Merry Christmas or any holiday you celebrate.]

Thank you very much for your help!!

I try to change the AEAW[2:0] from 100b to 011b, because I read some information about AEAW from datasheet of DM6437.When AEM[2:0]=001b,the AEAW[2:0] determines the address width of Flash. Then I found when the size of my project is lager then 100K(up or down),the boot cann't be successful,else boot works well.

I don't know what to do,then I change the AEAW back to 100b.But the boot can work successfully!!!

I was so surprised! How Strange it is!!

Now I haven't found the reasons!

Thank you very very much!!

Wish you happy!!

I met another problem and I need your help.

I do not know what "led sprink" is.

Can you verify if the program is loaded into the same memory locations using both methods?

In emulation, there are GEL scripts that run to initialize some peripherals or memory, so you will want to verify that all of these steps are done in your boot process also. If they are not, then some things may run slower. Here are things to check:

• PLL / DSP clock speed
• external memory interface configuration for the number of cycles for accesses
• cache settings
• MAR bit settings to enable cache
• memory segment locations

Please let me know what you find.

Regards,
RandyP

1、

RandyP said:

I do not know what "led sprink" is.

I made a mistake.I mean led-blink.

2、

RandyP said:

Can you verify if the program is loaded into the same memory locations using both methods?

 The only difference between the execution-file in the two methods is format,one is .ais,the other is .out. So I think both of them are located into the same memory.Am I right?

3、

RandyP said:

• external memory interface configuration for the number of cycles for accesses

Do you mean the configration of EMIF?

4、、

RandyP said:

• MAR bit settings to enable cache

I didn't find the reference document for MAR,where can I find it?

yan jie said:

So I think both of them are located into the same memory.Am I right?

Probably you are right. If it were me, I would verify that every section is located at the same address. I would do this by comparing the map files and by looking at the loaded program code using CCS.

yan jie said:

Do you mean the configuration of EMIF?

Yes. If the program or data is located in external memory but the wait states are different, then execution time could be different. This is one of several things to look at. Do you know that you have the same EMIF settings in both cases? You can view these registers with CCS and compare them.

yan jie said:

I didn't find the reference document for MAR,where can I find it?

The datasheet shows the addresses of the MAR bits, the C64x+ DSP Cache User's Guide discusses how the MAR bits are used, and the C64x+ DSP Megamodule Reference Guide discusses implementation details. All of these documents are available from the TMS320DM6437 Product Folder.

Regards,
RandyP

Thank you very much!!!!

 Yes,You are right!! It is the PLL clocl speed!!

Wish you happy everyday!!

Thank you very much!!

Yes,You are right! It is the PLL clock speed!!

Wish you happy every day!!