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.

TMS320C6678: C6678 ROM Bootloader getting lost

Part Number: TMS320C6678

We are booting our application from SPI NOR flash on the C6678.  We are not using the IBL, we are booting directly from the RBL.   We've have our application booting for a few months now, but at some point (we did something to break it.  We don't know what, because we normally run from the CCS Debugger since we are still debugging our code, and only occasionally store the image in Flash and boot using the RBL.   What we are seeing, is that when the RBL is loading the 2nd (.cinit) of 7 sections, it winds up at an invalid address: 0xA1380100.  What's curious about this address is that this value was loaded from flash just a few words before the RBL got lost.   I thought perhaps the RBL stack was getting clobbered, and perhaps it really is, but it doesn't appear to be.   The second image is 1db8 in size and is loaded to 873320.    It's also worth noting that when I compare the data in memory to the .bin file, there are 2 words that do not match what should have been copied.  Address 873348 contains 0042a120 but should be 003fa140 and the very last word written is 0087fffc but should be 07a1ff05.  Here's a screenshot of the registers and memory at that location (from CCS) when the RBL gets lost.  Notice the word at 87345c is the same as the PC.

  • The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • David,

    One thing that I noticed in your description that may be significant is that the C6678 Data Manual highlights some sections that are reserved by the bootloader and some of those sections seem to be in the region where you are trying to load application code so I would also try to locate that to parts of L2 memory that are not being used by the boot ROM. Check section 2.4 Boot Sequence in the data manual:
    www.ti.com/.../tms320c6678.pdf

    Those regions should be available for application to reuse after the ROM boot has exited. Can you try to relocate these sections and let us know if this issue is resolved. If not we can provide additional steps that may help debugging this boot issue.

    Regards,
    Rahul
  • Rahul,

    Thanks so much for getting back to me.  Yes, I can see from section 2.4 in the processor manual that this is definitely my problem.  I would be happy to relocation sections to avoid that, or perhaps make sure that some "uninitialized" section is there.....if only you would tell me how to do this?   I've got a linker.cmd file but it just says to put everything in L2SRAM.  We don't have DDR3 on our board because our genius H/W guys didn't think we needed any.

    David

    SECTIONS

    {

    .csl_vect > L2SRAM

    .text > L2SRAM

    GROUP (NEAR_DP)

    {

    .neardata

    .rodata

    .bss

    } load > L2SRAM

    .stack > L2SRAM

    .cinit > L2SRAM

    .cio > L2SRAM

    .const > L2SRAM

    .data > L2SRAM

    .switch > L2SRAM

    .sysmem > L2SRAM

    .far > L2SRAM

    .testMem > L2SRAM

    .fardata > L2SRAM

    platform_lib > L2SRAM

    }

  • David,

    There are multiple ways of doing this:

    Update your platform definition as shown here:
    e2e.ti.com/.../198130

    If you don`t prefer to change the platform definition then you can also explore the option of use loadAddress in the .cfg file as shown here:
    processors.wiki.ti.com/.../Processor_SDK_RTOS:_TI_RTOS_Tips_And_Tricks

    More tips are available in the TI RTOS user guide Memory section.

    Regards,
    Rahul
  • We really don't want to modify the platform definition file because that is not under source control and anyone building the code on a different machine wouldn't know about the change. I tried the second approach in my app.cfg file. The idea was to place the .far section at the end of L2SRAM at the location reserved for the ROM Bootloader since the .far section is "uninitialized". Here's how I did it:

    Program.sectMap[".far"] = new Program.SectionSpec();
    Program.sectMap[".far"].loadAddress = 0x00868000;

    But it didn't seem to do anything. Here's the result from the .map file:

    .far 0 00855f80 00014cf4 UNINITIALIZED
  • David,

    I think you misunderstood my point regarding creation of custom platform. My recommendation  was not to  manuallymodify the Platform file.  We provide RTSC Platform tool in CCS where you can create a new platform define in your project directory and update the Project RTSC settings to use that platform definition instead of the default ti.platforms.evmC6678. since the platform is in your project directory, you can keep it under source control.  An excellent example of this process is the image processing demo :

    processor_sdk_rtos_c667x_4_03_00_05\demos\image_processing\ipc\evmC6678l\platform

    Git.ti.com link:

    It is surprising that the uninitialized sections are not being placed as I have tried this on another device and this works without any issues.  I am providing a screenshot of this for your consideration. Can you rebuild the project and then see if you still see this issue.

    Regards,

    Rahul

  • Rahul,

    We did find a simple solution to our problem.  We modified our local C6678.cmd file to force the .far section to a specific address that covered the area reserved by the RBL.  The line looks like this:

          .far > 0x0086B000