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.

CCS/TMS320F28377D: C2000™ microcontrollers forum

Part Number: TMS320F28377D


Tool/software: Code Composer Studio

Hi.

I  develop a program, for a long time, that are locate on CPU1, CPU1_CLA, CPU2 and CPU2_CLA.

Recently, linker told me to extend program space for CPU2 (.text section in cmd file) and I execute this task as I did before for CPU1. For clarity, I attach the cmd file with previous comment statement modified:

// The user must define CLA_C in the project linker settings if using the
// CLA C compiler
// Project Properties -> C2000 Linker -> Advanced Options -> Command File
// Preprocessing -> --define
#ifdef CLA_C
// Define a size for the CLA scratchpad area that will be used
// by the CLA compiler for local symbols and temps
// Also force references to the special symbols that mark the
// scratchpad are.
CLA_SCRATCHPAD_SIZE = 0x100;
--undef_sym=__cla_scratchpad_end
--undef_sym=__cla_scratchpad_start
#endif //CLA_C

MEMORY
{
PAGE 0 :
   /* BEGIN is used for the "boot to SARAM" bootloader mode   */

   BEGIN           	: origin = 0x000000, length = 0x000002
   RAMM0           	: origin = 0x000080, length = 0x000380
   RAMD0           	: origin = 0x00B000, length = 0x000800
   RAMLS0           : origin = 0x008000, length = 0x000800
   RAMLS1          	: origin = 0x008800, length = 0x000800
   RAMLS2      		: origin = 0x009000, length = 0x000800
   RAMLS3      		: origin = 0x009800, length = 0x000800
// RAMLS4      		: origin = 0x00A000, length = 0x000800
// RAMLS5		    : origin = 0x00A800, length = 0x000800

// RAMGS0      	    : origin = 0x00C000, length = 0x001000
// RAMGS1      	    : origin = 0x00D000, length = 0x001000
// RAMGS2      	    : origin = 0x00E000, length = 0x001000
// RAMGS3      	    : origin = 0x00F000, length = 0x001000
// RAMGS4      	    : origin = 0x010000, length = 0x001000
// RAMGS5      	    : origin = 0x011000, length = 0x001000
   RAMGS0_TO_5 	    : origin = 0x00C000, length = 0x006000
// RAMGS6      	    : origin = 0x012000, length = 0x001000
// RAMGS7      	    : origin = 0x013000, length = 0x001000
// RAMGS8      	    : origin = 0x014000, length = 0x001000
// RAMGS9      	    : origin = 0x015000, length = 0x001000
// RAMGS10     	    : origin = 0x016000, length = 0x001000
// RAMGS11     	    : origin = 0x017000, length = 0x001000
// RAMGS12     	    : origin = 0x018000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
// RAMGS13     	    : origin = 0x019000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
// RAMGS14          : origin = 0x01A000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
// RAMGS15          : origin = 0x01B000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
   RAMGS14_STRUCT   : origin = 0x01A000, length = 0x000800
   RAMGS14_ADC_EXT  : origin = 0x01A800, length = 0x000800
   RAMGS15_STRUCT   : origin = 0x01B000, length = 0x001000
   RESET            : origin = 0x3FFFC0, length = 0x000002

PAGE 1 :

   BOOT_RSVD        : origin = 0x000002, length = 0x00007E      /* Part of M0, BOOT rom will use this for stack */
   RAMM1            : origin = 0x000400, length = 0x000400      /* on-chip RAM block M1 */
   RAMD1            : origin = 0x00B800, length = 0x000800

// RAMLS0           : origin = 0x008000, length = 0x000800
// RAMLS1          	: origin = 0x008800, length = 0x000800
// RAMLS2      		: origin = 0x009000, length = 0x000800
// RAMLS3      		: origin = 0x009800, length = 0x000800
   RAMLS4      	    : origin = 0x00A000, length = 0x000800
   RAMLS5		    : origin = 0x00A800, length = 0x000800

   RAMGS0      	    : origin = 0x00C000, length = 0x001000
   RAMGS1      	    : origin = 0x00D000, length = 0x001000
   RAMGS2      	    : origin = 0x00E000, length = 0x001000
   RAMGS3      	    : origin = 0x00F000, length = 0x001000
   RAMGS4      	    : origin = 0x010000, length = 0x001000
   RAMGS5      	    : origin = 0x011000, length = 0x001000
// RAMGS6      	    : origin = 0x012000, length = 0x001000
// RAMGS7      	    : origin = 0x013000, length = 0x001000
// RAMGS8      	    : origin = 0x014000, length = 0x001000
// RAMGS9      	    : origin = 0x015000, length = 0x001000
// RAMGS10     	    : origin = 0x016000, length = 0x001000
// RAMGS11     	    : origin = 0x017000, length = 0x001000
   RAMGS6_TO_11	    : origin = 0x012000, length = 0x006000
   RAMGS12     	    : origin = 0x018000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
   RAMGS13     	    : origin = 0x019000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
// RAMGS14          : origin = 0x01A000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
// RAMGS15          : origin = 0x01B000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */

   CANA_MSG_RAM     : origin = 0x049000, length = 0x000800
   CANB_MSG_RAM     : origin = 0x04B000, length = 0x000800

   CLA1_MSGRAMLOW   : origin = 0x001480, length = 0x000080
   CLA1_MSGRAMHIGH  : origin = 0x001500, length = 0x000080
}


SECTIONS
{
   codestart        : > BEGIN,     			PAGE = 0
// .text            : >> RAMD0 |  RAMLS0 | RAMLS1 | RAMLS2 | RAMLS3/* | RAMLS4*/,   PAGE = 0
   .text            : >> RAMD0 |  RAMLS0 | RAMLS1 | RAMLS2 | RAMLS3 | RAMGS0_TO_5,   PAGE = 0
   .cinit           : > RAMM0,     			PAGE = 0
   .pinit           : > RAMM0,     			PAGE = 0
   .switch          : > RAMM0,     			PAGE = 0
   .reset           : > RESET,     			PAGE = 0, TYPE = DSECT /* not used, */

   .stack           : > RAMM1,     			PAGE = 1
   .ebss            : > RAMLS5,    			PAGE = 1
   .econst          : > RAMLS5,    			PAGE = 1
   .esysmem         : > RAMLS5,    			PAGE = 1

   /* CLA specific sections */
   Cla1Prog         : > RAMLS4,    			PAGE = 1
// CLADataLS4		: > RAMLS4,    			PAGE = 1
   CLADataLS5		: > RAMLS5,    			PAGE = 1
   CLA1mathTables	: > RAMLS5,	   			PAGE = 1 			// Section Added at 04/2017

   Cla1ToCpuMsgRAM  : > CLA1_MSGRAMLOW,   	PAGE = 1
   CpuToCla1MsgRAM  : > CLA1_MSGRAMHIGH,  	PAGE = 1

// SHARERAMGS0		: > RAMGS0,				PAGE = 1
// SHARERAMGS1		: > RAMGS1,				PAGE = 1
// SHARERAMGS2		: > RAMGS2,				PAGE = 1
// SHARERAMGS3		: > RAMGS3,				PAGE = 1
// SHARERAMGS4		: > RAMGS4,				PAGE = 1
// SHARERAMGS5		: > RAMGS5,				PAGE = 1
// SHARERAMGS6		: > RAMGS6,				PAGE = 1
// SHARERAMGS7		: > RAMGS7,				PAGE = 1
// SHARERAMGS8		: > RAMGS8,				PAGE = 1
// SHARERAMGS9		: > RAMGS9,				PAGE = 1
// SHARERAMGS10		: > RAMGS10,			PAGE = 1
// SHARERAMGS11		: > RAMGS11,			PAGE = 1
// SHARERAMGS12		: > RAMGS12,			PAGE = 1     		/* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
// SHARERAMGS13		: > RAMGS13,			PAGE = 1     		/* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
// SHARERAMGS14		: > RAMGS14,			PAGE = 0     		/* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
   SHARERAMGS14_STR	: > RAMGS14_STRUCT,		PAGE = 0
   SHARERAMGS14_ADC	: > RAMGS14_ADC_EXT,	PAGE = 0
   SHARERAMGS15_STR	: > RAMGS15_STRUCT,		PAGE = 0			/* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */

#ifdef __TI_COMPILER_VERSION__
   #if __TI_COMPILER_VERSION__ >= 15009000
       .TI.ramfunc : {} > RAMM0,      PAGE = 0
   #else
       ramfuncs         : > RAMM0      PAGE = 0
   #endif
#endif

#ifdef CLA_C
   	/* CLA C compiler sections */
   	//
   	// Must be allocated to memory the CLA has write access to
   	//
   	CLAscratch       	:
                     		{ *.obj(CLAscratch)
                     		. += CLA_SCRATCHPAD_SIZE;
                     		*.obj(CLAscratch_end) } >  RAMLS5,  PAGE = 1

   	.scratchpad      	: > RAMLS5,       PAGE = 1
   	.bss_cla		    : > RAMLS5,       PAGE = 1
   	.const_cla	    	: > RAMLS5,       PAGE = 1

#endif //CLA_C
}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

Naturally, Linker stopped to show me error about lack program space but when I try to loading code with my debug session, following observations need to be made:

1) CPU1 code is loaded correctly and, at the end of total programming process, the debugger point to main address;

2) CPU1_CLA code is  loaded correctly and starting when I lunch CPU1 code to generate a sw trigger for various task;

3) CPU2 code seems to be loaded correctly...

2) CPU2_CLA code is  loaded correctly and waiting a sw trigger from CPU2 code.

After program stage are completed, console show me follow:

C28xx_CPU1: GEL Output: 

Memory Map Initialization Complete
C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
C28xx_CPU2: GEL Output: 
Memory Map Initialization Complete
C28xx_CPU2: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.

If I select Debug Tab I see that:

Differently than usual, CPU2 code start to run immediately... If I suspend it, console show me the follow error even if I don't insert any breakpoint:

C28xx_CPU2: Trouble Removing Breakpoint with the Action "Finish Auto Run" at 0x9800: (Error -1066 @ 0x9800) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 8.0.903.4) 

Finally, when I return in Debug Tab, I see CPU2 suspended where PC point to 0x3FE00A address where no symbol are defined. I obtain the same behavior if I load again code by load command (CPU2 running immediately and ...). I know, if I not in error, that address is a BOOT ITRAP; unfortunately, I don't understand where I stuck my cmd linker file. I tried to take a look at my map file but I didn't find nothing strange (obviously I attach that follow).

Can someone help me to understand what's going on? Thank's a lot.

Diego

<Edited to delete memory map file. Please re-attach as a file if necessary to debug>

  • Diego,

    Check out this forum post and see if you are able to get any insight for a solution.
    e2e.ti.com/.../596509

    Regards,
    Ozino
  • Hello Diego,

    I have a point of feedback for you. 

    Please avoid dumping this much content into an e2e post. You may notice that the fact you inserted a 2000 line file in the body, you have essentially degraded the quality of you post since now everyone will have to scroll for multiple seconds just to reach the end of a block of content that frankly will not be useful unless explicitly asked for - especially the memory map and linker files.

    If you do intend to share so much content, please limit the number of lines inserted, or wait to share files until they are requested from a TIer. and also attach it as a file, rather then embed it in the body of the post. I do want to thank you for formatting the code at least!

    Note- I have edited your post to delete the memory map file. please add it as an attachment if it is necessary to debug further,

    Also, the TI Thinks resolved button was clicked by accident, you may disregard this post as a resolution.

    Thanks,

    Mark

  • I apologise for any inconvenience that my thread might cause: I thought that by inserting code with specific tool it was considered like an image... It was my fault. Unfortunately, I just observed the thread provided by last advice (anyway thanks) and I had noted, with disassembled window, there is a dynamic bug that maybe modify code loaded in memory (zero value treated like ITRAP). I'm trying to search the issue. Thank's for your support.
  • Diego,

    What errors are you observing regarding your linker command file?

    Here is a post about illegal ISRs when using shared RAM across CPUs.
    e2e.ti.com/.../1791385

    Regards,
    Ozino
  • Diego,

    I read through the console window messages that you posted and wanted to clarify one thing.

    Regarding the console message "C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed"You can ignore this message since you are not using Flash based linker command file (based on the linker cmd file contents that you posted).  This message gets printed in the console window when you connect the debugger to highlight that Flash Plugin uses shared RAM for executing the Plugin code (that erases/programs/program-data buffer).  In your case, Flash Plugin will not get invoked as you don't have any sections mapped to Flash address range.

    Regarding the CPU2 issue that you noticed: If CPU2 is using shared RAM, make sure CPU1 executes first and gives the shared RAM ownership to CPU2 as appropriate.  May be CPU2 is trying to execute it's code from shared RAM and is fetching all zeros as it does not have ownership? - Please check.

    Thanks and regards,
    Vamsi

  • Diego,

    Are you able to find the ITRAP cause?
    Can I close this post? Or Do you have any further questions? Please let us know.

    Thanks and regards,
    Vamsi
  • Hi Vamsi.

    Yes, I found my fault: I writing in ram with pointer in wrong way.

    So, you can close this post. Thanks.
  • Diego,

    I am glad that your issue is resolved.

    I am closing this post.

    Thanks and regards,

    Vamsi