• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 803 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6727 Parallel Flash Boot, SDRAM, TISecondaryBoot and System Patch Issues

Shane O'Malley
Prodigy 10 points

Hello Everyone,

My team and I are running into some issues trying to Flash Boot using the AIS parallel flash method with the default TISecondaryBoot.

Using: CCS 5.5, Compiler TI v7.4.5, DSP/BIOS 5.42.1.09

We are using the 6727+ DSP with Micron SDR SDRAM and Numonyx J3 SBC Flash Memory. We compiled and linked our code with the generated cfg.c, called in the secondaryboot through the .cmd, used genAIS with the cooresponding .cfg, bootmode tisecboot -pf 16 and burned the resulting binary file to flash. 

We are compiling with trampolines on globally. TConf Large data model and using the rts67plus.lib

 All optimizations turned off for the cfg.c and TISecondaryBoot.c files as well as "far" Data access model enabled. We found we had to make these changes in order for the SecondaryBoot to properly load the entire AIS into IRAM and SDRAM properly. 

 When we boot the system, all indications are that the entire program was read correctly from flash memory into the appropriate 6727 IRAM and external SDRAM. No CRC errors (or other) are generated by the loader and if we spot check sections of NVM versus the contents of SDRAM & IRAM, everything looks correct.

 However, the loaded program does not execute properly and when we connect to it through our emulator the program counter is at an illegal addresses (i.e. 0xF00000C0 or other non RAM/ROM address locations).

 One thing we noticed when looking through the load map is that the BOOT ROM patch code (c672xSystemPatchV2_00_00.lib & applySystemPatch.obj) is linking and being placed into SDRAM, which doesn’t seem right. The patch supposedly gets executed before the SDRAM is even initialized, is that a correct assumption? According to the .map, the patch is linked into SDRAM under .text. Shouldn’t the patch be forced to load into IRAM so the ROM BOOT can read it properly? How do we cause this to happen in the compiler? Our application is rather large so the .text section must be in SDRAM, it won’t fit into the DSP IRAM. We have attempted to load it using both recommended methods (-l in the .cmd and linking through CCS, including them in the project).

 Does this booting problem sound like a patch issue? Compiler/linker issue? We have tried several dozen compiler/linker combinations as well as various modifications to our .cmd and .tcf.  Any help or direction anyone can provide us will be greatly appreciated.

  • 0
    TI__Guru* 84110 points

    Shane,

    Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics.

    Your AIS file will generally have a series of SET commands that take care of certain peripheral initializations, especially the SDRAM init and speeding up the EMIF for the Flash (not required). This way, the patch code can safely sit in SDRAM or IRAM, whichever is most convenient for your application.

    Most of the time, booting issues are related to peripherals that are not initialized properly. During CCS development with the emulator, a GEL script is usually connected through the Target Configuration and that GEL script takes care of all the system configuration of PLLs and peripherals. If any of that initialization is not done in the AIS SET commands or in the bootloaded code, there can be problems like what you describe.

    There is a Wiki article on debugging boot problems. Please go to the TI Wiki Pages and search for "debug boot" (no quotes) to find this article with several helpful bits of advice.

    The fact that you have no CRC errors and the code seems to match the Flash contents, that says you have the SDRAM initialized correctly.

    The first step I would take is to disconnect the GEL script, load your program from CCS, and run it to confirm that it will work correctly from CCS-based load. If it runs okay but the Flash version does not, then there is something in the Flash init/bootload that is not getting initialized correctly.

    The next step I would take is to disconnect the GEL script, load your program from CCS without running to main(), and capture the contents of IRAM and SDRAM into memory-save files. Then go through the boot process and capture the contents into another memory-save file so you can compare the two fully. It may be a pain getting through uninitialized data sections and unintialized holes at the end of loaded sections, so you may want to load as many 0's as you can into IRAM and SDRAM, if that is at all possible, or maybe there is a way to tell the linker to fill everything with 0's that it does not use.

    Please let us know if any of this helps, or what results you get from some of these tests and from the Wiki article.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 15 points

    RandyP,

    Thank you for your response, explanations, and suggestions!  After additional troubleshooting and testing, we determined that it was a memory fill in our command file that was preventing one method or the other from working properly (CCS loading or Flash loading)

    In our command file, we originally had memory sections being filled with zeros. When this fill is in place, our load from CCS works perfectly fine. During the flash boot, if we have any of these zero fills in the command file, the SecondaryBoot and AIS load fails. We searched through the help and various sites trying to find the explanation to this behavior. Our assumption is that the memory fills in the .cmd file are executed partially through the SecondaryBoot process and essentially wiping out its own data. Can you or anyone confirm this? Is there anyway to perform this memory fill before the SecondaryBoot? Perhaps explain why the CCS version of the build requires the memory fills for proper function and the flash does not?

    Currently we have a working program in flash and CCS, we just have to use different .cmd files. While it is working, we are trying to fully understand the behavior and differences in CCS and FlashBoot application loading.

    Thank you!
    Shane

  • 0 in reply to Shane OMalley
    TI__Guru* 84110 points

    Shane,

    There are multiple ways to implement "fill" in the linker command file. You can fill holes in initialized sections and you can fill uninitialized sections. You can end up creating a huge .out file, for the latter, and I am guessing the initialized sections are what are causing the problems, but I need to know exactly what you were doing to understand how it can affect your results.

    Can you show the differences between the two versions of your .cmd file?

    Which memory model are you using? (-c or -cr, aka --rom_model or --ram_model, resp.)

    Regards,
    RandyP