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: Custom program load

Part Number: TMS320C6678

Hi all,

We are facing some difficulties in customizing the loading process on

our DSP. The DSP should load by default only Core0 executable. Then

at runtime, Core0 should load a custom executable on Core1.

We searched TI official documentation and this forum too with no vail.

The theory behind the process is really clear but the implementation

requires more information. We are looking for an example or a step

by step guide.

Can someone please help us?


Best regards,

Giovambattista Astorino

Code Composer 6.2.0

PDK 2.0.4

SYS/BIOS 6.46.1.38

  • Hi Giovambattista Astorino,

    I've forwarded this to the c66x experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • Hi,

    Something I know is we have different boot modes, the application can be loaded from media like NAND, NOR, or interace like Ethernet, PCIE into cores and let them run. We usually loads core 0, some times we also load core 0 with other cores. But we didn't use core 0 to load something into core 1. Do you have a usage scenario that uses core 0 to load core 1 and run? Why this is needed?

    For a PCIE boot case I am familiar with,
    1) host PC established a PCIE link between PC and C6678,
    2) then PC writes the application into core 0, the application is converted from .out into a data array
    3) the PC writes the DSP start address to let core0 to run

    The example is under mcsdk_2_01_02_06\tools\boot_loader\examples\pcie please read the readme.pdf. You don't need to read to much into the example code. From your case, core 0 is the PC, core 1 is the core 0 for the above discussion:

    -- there is an application .out intended to run in core 1, you need to convert this into a data array, then core0 just does a write block-by-block of this array into core1's memory, please refer to pushData() in pciedemo.c
    -- core 0 writes DSP_BOOT_ADDRESS of core 1 with the starting address
    -- core 0 sends an IPC interrupt to core 1, core 1 should starts to run

    In summary, .out file needs to be converted to a bootable array format, core0 has code to parse this bootable array and write it into core1, then core0 sends interrupt for core 1 to start.

    Hope this help!

    Regards, Eric
  • Hi Eric,

    Thanks for your reply. I have some difficulties in finding the example. I don't have any mcsdk but instead PDK 2.0.4. I cannot find the directory with the example and in particular the .pdf guide

  • You can find the same examples under :
    pdk_c667x_2_0_4\packages\ti\boot\examples\pcie

    HEre are instructions and an example that demonstrates waking up secondary cores from Core0:
    processors.wiki.ti.com/.../KeystoneI_Bootloader_Resources_and_FAQ

    Regards,
    Rahul
  • Hi Rahul,

    Thanks for your reply. I still have some problem with the example.

    I used the pdkAppImageCreate.bat script in C:\ti\pdk_c667x_2_0_4\packages

    to create the example ccs project but it doesn't find that particular example.

    I'm trying to create the project manually starting from the files in the folder

    but I'm facing a lot of compilation errors. Is there a script that creates

    the ccs project of that particular example?

    Thanks

    Giovambattista

  • Hi,

    The pdf file is missing in Processor SDK RTOS that is why I suggested the MCSDK. See the attached. You don't need to create any CCS project as this is PCIE boot example, what I suggested is to read a few functions to understand what the bootable image format is, then you use core 0 to writes the image into core 1, as if in the PCIE boot case where host PC writes boot image into core 0.

    Regards, Eric5850.README.pdf

  • Previously in MCSDK 2.x, we provided CCS projects that could be imported and built to rebuild the example.  In Processor SDK RTOS, these projects have been migrated to makefile based builds that can be built using the instructions that we provide here:

    To build the same using make files in Processor SDK RTOS installed under Windows you can follow these instructions:

    • Setup SDK build environment as described Setup_Environment
    • Change directory to example and build:
    cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie/pcieboot_ddrinit/<platform>/build
    
    gmake all
    
    cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie/pcieboot_helloworld/<platform>/build
    
    gmake all

    To run these examples on the EVM, Eric has provided the ReadME document that describes the hardware setup

  • Hi,

    I still have some problem about this task. We have a .out file we want to load to coreN from core0. We used the following scripts:
    - hex6x.exe
    - Bttbl2Hfile
    - hfile2array

    The output from the last script is a .h file with only an array with 8 bit elements arrangement in which is stored the original .out.

    Core0 then writes the pointer to this array on the boot magic address of every other cores. Finally, Core0 triggers the IPC interrupt to wake the cores.

    The problem is that it doesn't work. I think that the 8bit element array must be manipulated somehow but I cannot find documentation about it.

    Can you please help me?

  • Hi,

    "Core0 then writes the pointer to this array on the boot magic address of every other cores."  =====> core 0 needs to parse this array with starting address, length ... etc and write this into other core 1-7.

    please refer to pushData() in pciedemo.c.

    The format looks like:

    0x00, 0x83, 0xCD, 0xE0, 0x00, 0x00, 0xD5, 0xA0, 0x00, 0x83, 0x00, 0x00, 0xAC, 0x45, 0x8C, 0xF7, 0x02, 0x00, 0x04, 0x2A, 0x02, 0x10, 0x80, 0x6A,

    0x6C, 0x6E, 0x10, 0x4D, 0xB2, 0....

    0x00, 0x00, 0x02, 0x94, 0x00, 0x84, 0x77, 0xDC, 0x14, 0x04, 0x04, 0x00, 0x00, 0x00, 0x12, 0x00, 0x13, 0x04, 0x01, 0x00, 0x00, 0x00, 0x22, 0x00,
    0x13, 0x04, 0x02, 0x00, 0x00, 0x04, 0x24, 0x00, 0x72,

    The green is boot address

    The yellow is the length of the first block

    The red is the starting address of the first block, following the red is the real block data.

    Then come to the next block (length, start address, data) 

    Note you typically has several blocks.

    Regards, Eric