Loading Multiple .elf files in one debug session

[girishraobulusu]

Hi,

Target: MPC5675KEVB257 evaluation board.

Development Environment : IDE:  CodeWarrior for MCU  Version: 10.5

Target Interface: USB Qorivva Multilink For MPC55xx/56xx (USB-ML-PPCNEXUS)

I am working on the MPC5675K evaluation board on Codewarrior 10.5. (My target memory is RAM as of now) From what I understand, in DPM mode Core_1's Program counter is loaded with the address vector from where to start execution, and this wake up sequence is initiated by core_0.

Now typically codewarrior10.5 creates one .elf which has memory and section segregation for each core.

However, I wish to create separate binaries for Core_0 and Core_1 (say Core_0_helloworld.elf and Core_1_helloworld.elf) and load it separately through codewarrior10.5. And then within the core_0 code provide the absolute address of the entry point of  Core_1_helloworld.elf to the DPMBOOT ADDRESS.

Please advise on how to load multiple .elf files in debug session and then start execution.

Thanks in advance!

[Jorge_Gonzalez]

Hello:

From what you ask, it sounds like the procedure explained by colleague Erich Styger in his MCU on Eclipse blog might be helpful:

Adding Symbols to the CodeWarrior Debugger | MCU on Eclipse

Regards!

/Jorge Gonzalez

[girishraobulusu]

Hi Jorge,

Thanks for the input, but I think the link is for debugging a target already loaded with the code and we also have the .elf/binary available with us for loading the symbols.

The post mentions: "Basically it means to tell the debugger the debug information of other applications, which are already running on the board...."

What I was looking for is that  2 .elf files be downloaded at the same time, within one debug session onto RAM/FLASH.

Also a very basic doubt I had was - would the following approach work for loading 2 binaries ? :

loading Core_1 binary and then loading Core_0 binary at a different memory location (since the 2 linker files are configured such way)  - hoping that during this download of second binary the first one is not erased from RAM.

Thanks for taking the time..

Regards,

Girish Rao Bulusu

[HCatalin · Accepted solution]

Hi Girish,

The CW feature you might want use is Debug Other Executables.

Basically, it allows to download and debug additional elf besides the main application.

For more details please check the following CW guide: {CW MCU v10.xhome dir}\MCU\Help\PDF\CodeWarrior Common Features Guide.pdf, section 3.16 Load Multiple Binaries.

Hope this helps,

Catalin

[girishraobulusu]

Hi Catlin,

Thanks for the input. Just to summarize the thread discussion for future reference.

As mentioned by Jorge in the previous post and Catalin, additional .elf files can be added using the : Debug Other Executables setting.

The detailed steps are given in the link below:

Adding Symbols to the CodeWarrior Debugger | MCU on Eclipse

Thanks and Regards,

Girish Rao Bulusu

[Jorge_Gonzalez]

Hello Girish:

You are right, I think I jumped the gun, sorry for the spam.

If you cannot find or do not receive answer you can always submit a service request so the experts can give advice.

Regards!

Jorge Gonzalez

[girishraobulusu]

Hi Jorge,

You were right and I was the one who jumped the gun after all. Thanks for the input. I really appreciate your help.

Regards,

Girish Rao Bulusu

[tektronix]

Hello Girish Rao

I am looking for the same thing. BTW in DPM the other core has a different address range for SRAM. Do you know where in CW we  can change the address of the RAM for other core. I am using MPC5643L but I guess setting must be same. Right now my both cores are running from memory region of 0x40000000 I want to make one core run from 0x50000000

[girishraobulusu]

Hey,

Sorry for delayed response.. I am aware of the restricted RAM memory access for each core and for this I have been working on the linker script to ensure that core_1 is running from 0x50000000. In-fact the default .lcf file generated by Codewarrior itself does the memory segregation in the following manner: (This is for MPC5675K and i presume would be the same for MPC5643L)

   exception_handlers_p0: org = 0x40000000,    len = 0x00002000 /* 8K core_0 */

   exception_handlers_p1: org = 0x50000000,    len = 0x00002000 /* 8K core_1 */

   internal_ram_p0:    org = 0x40002000,       len = 0x00030000 /* 192K core_0 */

   internal_ram_p1:    org = 0x50002000,       len = 0x00030000 /* 192K core_1 */

   heap:               org = 0x40032000,       len = 0x00008000 /* 32K heap core_0 */

   stack:              org = 0x4003A000,       len = 0x00006000 /* 24K stack core_0 */

   heap_p1:            org = 0x50032000,       len = 0x00008000 /* 32K heap core_1 */

   stack_p1:           org = 0x5003A000,       len = 0x00006000 /* 24K stack core_1 */

Hope this helps.

Also, as of now my approach for loading 2 binaries onto RAM has been loading Core_1 binary and then loading Core_0 binary  - hoping that during this download of second binary the first one is not erased. But this rather not-so-efficient approach does not seem to be working. I suspect RAM is cleared/erased completely every-time it is loaded with something.

Do let me know if you've been able to come up with another approach.

Thanks

[tektronix]

Hello Girish

Thanks for the help.If you are using ICDPPCNEXUS you can load two binaries using following method.

Z4_1Hload

Z4_0Hload

[tektronix]

Hello again Girish,

If you are downloading using Multilink debugger there are many ways you can download to files. Anyway can you tell how did you generated two files using CodeWarrior?. I will try your suggestion and see if that help. Here is my linker command file

/* lcf file for MPC5643L processors, running in DPM (dual core) mode        */

/*                                                                          */

/* Note internal memory configurations vary among the various family        */

/* devices.                                                                 */

/*                                                                          */

/*   +-----------+------------+                                */

/*   |  Device   | MPC5643L   |                                 */

/*   +-----------+------------+                                 */

/*   |SRAM/Flash | 128KB/1MB  |                                 */

/*   |           |            |                               */

/*   +-----------+------------+                               */

/*                                                                          */

/* These memory definitions will allow the stationery example to run on     */

/* the smallest, i.e. MPC5643L device's internal memory (1MB   Flash,       */

/* 128KB SRAM).                                                              */

MEMORY

{

    pseudo_rom:             org = 0x40000000,   len = 0x00006800

    init:                   org = 0x40006800,   len = 0x00000800

    exception_handlers_p0:  org = 0x40007000,   len = 0x00001000

    internal_ram:          org = 0x40008000,   len = 0x00005000

    heap  :                 org = 0x4000D000,   len = 0x00001000 /* Heap start location */

    stack :                 org = 0x4000E000,   len = 0x00002000 /* Start location for Stack */

    /* Split map for the second core */

    exception_handlers_p1:  org = 0x50000000,   len = 0x00001000

    internal_ram_p1:      org = 0x50001000,   len = 0x0000B000

    heap_p1  :              org = 0x5000C000,   len = 0x00001000

    stack_p1 :              org = 0x5000D000,   len = 0x00003000

}

SECTIONS

{

    GROUP : {

      .init  : {}

      .init_vle (VLECODE) : {

        *(.init)

        *(.init_vle)

      }

    } > init

    GROUP : {

      .ivor_branch_table_p0 (VLECODE) ALIGN (2048) : {}

      .intc_hw_branch_table_p0 ALIGN (2048) : {}          

      .__exception_handlers_p0 (VLECODE) : {}

    } > exception_handlers_p0

    GROUP : {

      .ivor_branch_table_p1 (VLECODE) ALIGN (2048)  : {}

      .intc_hw_branch_table_p1 ALIGN (2048) : {}  

      .__exception_handlers_p1 (VLECODE) : {}

    } > exception_handlers_p1

    GROUP : {

      .intc_sw_isr_vector_table_p0 ALIGN (2048) : {}

      .intc_sw_isr_vector_table_p1 ALIGN (2048) : {}

        .text (TEXT) ALIGN(0x1000) : {}

        .text_vle (VLECODE) ALIGN(0x1000): {

             *(.text)

             *(.text_vle)

         }

        .rodata (CONST) : {

            *(.rdata)

            *(.rodata)

        }

        .ctors : {}

        .dtors : {}

        extab : {}

        extabindex : {}

    } > pseudo_rom

    GROUP : {   

       .__uninitialized_intc_handlertable ALIGN(0x10) : {}

       .data   : {}

       .sdata  : {}

       .sbss   : {}

       .sdata2 : {}

       .sbss2  : {}

       .bss    : {}

    } > internal_ram

}

/* Freescale CodeWarrior compiler address designations */

_stack_addr = ADDR(stack)+SIZEOF(stack);

_stack_end  = ADDR(stack);

_heap_addr  = ADDR(heap);

_heap_end   = ADDR(heap)+SIZEOF(heap);

_stack_addr_p1 = ADDR(stack_p1)+SIZEOF(stack_p1);

_stack_end_p1  = ADDR(stack_p1);

_heap_addr_p1  = ADDR(heap_p1);

_heap_end_p1   = ADDR(heap_p1)+SIZEOF(heap_p1);

/* Exceptions Handlers Location (used in Exceptions.c for IVPR initialization) */

EXCEPTION_HANDLERS = ADDR(exception_handlers_p0);

EXCEPTION_HANDLERS_P1 = ADDR(exception_handlers_p1);