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.

C6672 - how to boot at one time two cores, each with own, independent executable .out file

Other Parts Discussed in Thread: TMS320C6672

Hello.

I have two different *.out executable files for C6672 cores. The first exe file is "CORE0.out" and the second is "CORE1.out". All code sections in CORE0 should be located into L2-CORE0 memory. All CORE1 code sections should be loacated into L2-CORE1 memory.

I would like to boot all cores at one time. I can flash SPI-MEMORY and I am able to boot CORE0. I know that I can copy the "L2-image-core0" to "L2-memory-core1" but I do not want to solve it in that way. I need two independent threads/calc. There are no DDR3 memory devices on my board.

So far, I am thinking about two *.out files convertion and synthesis based on hex6x tools but I am not really sure is this right direction?

The best help for mi will be a script...

Best Regards

Pawel

  • 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 (for processor issues). Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics (e2e.ti.com). Please read all the links below my signature.

    We will get back to you on the above query shortly. Thank you for your patience.

    Note: We strongly recommend you to create new e2e thread for your queries instead of following up on an old/closed e2e thread, new threads gets more attention than old threads and can provide link of old threads or information on the new post for clarity and faster response.

  • Hi Pawel,

    Please walk through the MAD demo provided in below link,

    Thank you.

  • Hi.

    Thank you for your answer. It seems to me that it is not about because:
    1. I do not have starter-kit or EVM only custom board
    2. system is a poor - one TMS320C6672 and one 128Mb spi-flash
    3. there is no i2C EEPROM, there is no DDR3, no XDS emulator
    4. dsp silicon version is the new and I do not have to use IBL (no i2C eeprom on the board)

    I think, It solution must exists but somewhere on low level. Tell me like an expert - can I use hex6x utility to merge two exe/out file into one boot table? The boot table contains info about entry point of first exe/out and information about the rest sections. First app can wake up the second core (core1). Form the other hand, the RBL should locate the app2 sections in L2CORE1 mem. I will try that approach. However I'll be grateful for replay. I have just studied a lot of materials/papers but seems to be concentrated around EVM board.

    Best regards
    Pawel
  • Raja,
    a few seconds ego I've just started the system. Hex6x utility can merge two out/exe file to one boot table. App1 - is realized by core0 form L2CORE0, App2 is realized by core1 from L2CORE1. The goal is to wake CORE1 after RBL finished its job. But - we have to know the _c_int00 address of app2. At now, It is a constant value in app1. Methink I use header dependencies capability to transport the entry point of core1 app2 to the app1 or... I can map the constant with value of _c_int00 (of app2) in shared mem.

    Regards
    Pawel
  • The problem of "C6672 - how to boot at one time two cores, each with own, independent executable .out file" has been solved. At now, I would like to summarize the topic.

    1. The TMS320C6672 is a two core DSP devices. There is two kind of memories: on-chip and off-chip. On-chip memory is divided into 3 groups: internal memory for core0 (L2D_CORE0, L2P_CORE0, L2_CORE0), internal memory for core1 (L2D_CORE1, L2P_CORE1, L2_CORE1)and shared memory (MSM). The 'address' value can be local or global. The word global means that 'this' memory region is recognized by all chip cores and modules. For map file creating process we should remember about it.

    2. We are interested in system which core0 and core1 perform own 'independent' code only in L2 memory. The size of this memory is 512kB. The 52kB in last sectors of this memory is used by RBL during boot process. The 4 last byte of this memory, located at address 0x1183FFFC is a magic word. If core0 wakes up the core1, the core1 first activity is read the magic word, jump to the location indicated by these 4-byte value. It is 'entry point' of application for core1. There is examples where the magic word is written by core0. Ok but we propose other solution. The magic word is obtain form core1 CCS project and put into 0x1183FFFC by RBL (Rom Boot Loader). There are two places where the 'action' should be done.

    Core1_*.c

    extern far unsigned int _c_int00;

    #pragma DATA_SECTION(entrypoint,"entry_point")

    const unsigned int entrypoint = (unsigned int)&(_c_int00);

    and Core1_*.cmd

    MEMORY

    {

       CORE1_L2_SRAM: o = 0x11800000 l = 0x0007FFFC

       L2_ENTRYPOINT: o = 0x1187FFFC l = 0x00000004

    }

    SECTIONS

    {

          .text        > CORE1_L2_SRAM

           /*other section omitted for clarity*/

           entry_point  > L2_ENTRYPOINT

    }

     

    We can see the result in *.map file.

    CORE1_L2_SRAM         11800000   0007fffc 0000486c 0007b790 RWIX

    L2_ENTRYPOINT         1187fffc   00000004 00000004 00000000 RWIX

     

     

     

    3. What the core0 should do only... the core 0 must wakes up the core1 by formula

           //wake the CORE1

           DEVICE_REG32_W(IPCGR1, 1);

     

    4. After successful compilation of both project (for cor0 and core1) in Code Composer Studio we can use the hex6x utility. The *.rmd file:

    core0.out

    core1.out

    -a

    -boot

    -e _c_int00

    -order L

     

    ROMS

    {

                   ROM1: org = 0x0C000000, length = 0x400000, memwidth = 32, romwidth = 32

                   files = {merge_boot_tables.btbl}

    }

    Why 0x0C00000? beacuse if it is 0x0 we loss one row... but is a another topic. It does not matter here.

     

    5. Now, we must flash boot table and boot parameter table into spi-flash or other devices/location accepted by RBL. (I have written own soft for downloading the code to spi because I have problems with byte ordering, swapping etc. - one again, it is the other story).

     

    So far the presented solution works. The IBL, DDR3 and MSM are not necessary.

    Best regards.

    Pawel