TMS320F28386D: CLA not updating properly part of a structure

Clément Letonnelier

Expert 2606 points

Part Number: TMS320F28386D
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Hello,

I have a CLA task that is triggered by the C28x core software.

The code of the task is pretty simple:

Fullscreen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
__interrupt void step(void)
{
    __mdebugstop();
    GPIO_togglePin(40U);
    G_U.V1  = ADC_readResult(ADCBRESULT_BASE, ADC_SOC_NUMBER0);
    G_U.V2  = ADC_readResult(ADCCRESULT_BASE, ADC_SOC_NUMBER0);
    G_U.Vex = ADC_readResult(ADCDRESULT_BASE, ADC_SOC_NUMBER0);
    G_U.i   = exec_count;
    if (exec_count == 36)
    {
        exec_count = 0;
    }
    else
    {
        exec_count++;
    }
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

__interrupt void step(void)
{
    __mdebugstop();

    GPIO_togglePin(40U);

    G_U.V1  = ADC_readResult(ADCBRESULT_BASE, ADC_SOC_NUMBER0);
    G_U.V2  = ADC_readResult(ADCCRESULT_BASE, ADC_SOC_NUMBER0);
    G_U.Vex = ADC_readResult(ADCDRESULT_BASE, ADC_SOC_NUMBER0);
    G_U.i   = exec_count;

    if (exec_count == 36)
    {
        exec_count = 0;
    }
    else
    {
        exec_count++;
    }
}

The manipulated variable are defined like that in C28x core code:

Fullscreen

1
2
3
4
5
#pragma DATA_SECTION(G_U,"Cla1DataRam")
G_ExternalInputs G_U;
#pragma DATA_SECTION(exec_count,"Cla1ToCpuMsgRAM")
int16_t exec_count;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#pragma DATA_SECTION(G_U,"Cla1DataRam")
G_ExternalInputs G_U;

#pragma DATA_SECTION(exec_count,"Cla1ToCpuMsgRAM")
int16_t exec_count;

The structure type definition is the following:

Fullscreen

1
2
3
4
5
6
7
typedef struct {
  uint32_T V1;                         /* '<Root>/V1' */
  uint32_T V2;                         /* '<Root>/V2' */
  uint32_T Vex;                        /* '<Root>/Vex' */
  int32_T i;                           /* '<Root>/i' */
  uint32_T PinProg;                    /* '<Root>/PinProg' */
} G_ExternalInputs;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

typedef struct {
  uint32_T V1;                         /* '<Root>/V1' */
  uint32_T V2;                         /* '<Root>/V2' */
  uint32_T Vex;                        /* '<Root>/Vex' */
  int32_T i;                           /* '<Root>/i' */
  uint32_T PinProg;                    /* '<Root>/PinProg' */
} G_ExternalInputs;

When I run the code, the variable are updated properly, except for the V1 element in the G_U structure which stays at 0.

I ran the code with the debugger to try to understand and the corresponding assembly is the following:

I must admit there is one odd thing I don't understand in that dissassembly is the line which gets replaced by .word 0x7BC0.

But anyways, when I ran it step by step, MR0 does contain the correct value after the MMOVZ16 MR0,@xb20

But then it goes to 0 after the first NOP following the MMOV32 @0x9808, MR0 and thus the 0 is stored in the structure item.

This behavior does not happen for the other variables of the structure, there I see the MR0 register changing accordingly to the execution of the MLSR/MMOV along while the NOP executes.

Not sure what is going on there, any ideas ?

Clément

2 months ago

0 Delaney Woodward 1 month ago

TI__Genius 13525 points

Hi Clément,

The .word 0x7BC0 line (which is only present in the Disassembly for V1) should just be allocating space in memory for the value 0x7BC0. I'm not sure why the compiler has this line. I will loop in the compiler team to see if it could be due to that. Also, do you have any compiler optimizations turned on for your project?

Best Regards,

Delaney

0 Clément Letonnelier 1 month ago in reply to Delaney Woodward

Expert 2606 points

Hello Delaney,

Not really no, we are only using -o0.

But anyways, the problem is not optimizations, as I said the assembly code is not behaving as expected either as you can see from the behavior I described.

Clément

0 Clément Letonnelier 1 month ago in reply to Clément Letonnelier

Expert 2606 points

I investigated a bit, the memory shows at the corresponding instruction address (read from CLA side):

So as you can see, the 0x7BC07625 is incorrect, it should be 0x7BC003C.

Oddly enough, I changed the build options to keep the asm files and the instruction is correct there:

What is strange is that the memory read from CPU side seems fine:

EDIT:

After some further testing and without doing anything except at some point modifying the corresponding memory address, it started working.

I am very annoyed by that as I am not able to replicate the issue anymore and have no real explanation.

Could it be that the memory slot was stuck somehow ?

0 George Mock 1 month ago in reply to Clément Letonnelier

TI__Guru**** 244120 points

Let's go back to this sentence from the first post.

Clément Letonnelier said:
I must admit there is one odd thing I don't understand in that dissassembly is the line which gets replaced by .word 0x7BC0.

I don't think the compiler put that there. There is another disassembler that comes with the compiler named dis2000. It is in the same \bin directory as the compiler cl2000. Run a command similar to:

Fullscreen

1
dis2000 executable_file.out > disassembly.txt
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

dis2000 executable_file.out > disassembly.txt

Inspect the disassembly. Does the address 0x9024 show .word 0x7BC0? I suspect it does not. Which mean the problem happens between when the build is complete, and when you look at the disassembly in the debugger.

Thanks and regards,

-George

0 Clément Letonnelier 1 month ago in reply to George Mock

Expert 2606 points

Hello George,

It does not indeed.

Honestly I am a little lost on what would have been wrong, I checked if it wasn't my code messing around with the CLA dataram before passing the ball but couldn't find anything.

The issue is gone as I highlighted in the second post but I am a bit annoyed by the fact that I have no explanations on what had been wrong.

Clément

0 Ki 1 month ago in reply to Clément Letonnelier

TI__Guru**** 450031 points

Hello,

Please note that due to the extended weekend (Holiday on February 17th), a response may not come until Tuesday of next week.

Thanks

0 Delaney Woodward 1 month ago in reply to Ki

TI__Genius 13525 points

Hi Clément,

This seems like it may be a memory issue. A couple questions I have:

1. Have you modified the linker cmd file from one given in C2000ware?

2. Can you check the map file and verify where the each part of the G_ExternalInputs structure is being placed in memory? On your device LSRAM0-7 are all accessible by the CLA but you can verify which are being given CLA permissions by checking the LSxMSEL and LSxCLAPGM registers?

3. You are doing a flash build, is that correct? If so, can you verify the entire Cla1ProgLoadSize and Cla1ConstLoadSize are being copied over at runtime?

Best Regards,

Delaney

0 Clément Letonnelier 1 month ago in reply to Delaney Woodward

Expert 2606 points

Hi Delaney,

Yes, I definitely did.
It was in LS2 and the CLA had the right permissions.
No I was doing a RAM build

Clément

0 Delaney Woodward 1 month ago in reply to Clément Letonnelier

TI__Genius 13525 points

Hi Clément,

Ok, are you able to send over your linker cmd and map file so I can take a look? Or for the linker cmd can you show snippets of what you changed?

Best Regards,

Delaney

0 Clément Letonnelier 1 month ago in reply to Delaney Woodward

Expert 2606 points

Hi Delaney,

The linker command file:

Fullscreen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CLA_SCRATCHPAD_SIZE = 0x100;
--undef_sym=__cla_scratchpad_end
--undef_sym=__cla_scratchpad_start
MEMORY
{
   /* BEGIN is used for the "boot to SARAM" bootloader mode   */
   BEGIN            : origin = 0x000000, length = 0x000002
   BOOT_RSVD        : origin = 0x000002, length = 0x0001AF     /* Part of M0, BOOT rom will use this for stack */
   RAMM0            : origin = 0x0001B1, length = 0x00024F
   RAMM1            : origin = 0x000400, length = 0x0003F8     /* on-chip RAM block M1 */
//   RAMM1_RSVD       : origin = 0x0007F8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
   RAMD0            : origin = 0x00C000, length = 0x000800
   RAMD1            : origin = 0x00C800, length = 0x000800
   RAMLS0           : origin = 0x008000, length = 0x000800
   RAMLS1           : origin = 0x008800, length = 0x000800
   //RAMLS2           : origin = 0x009000, length = 0x000800
   //RAMLS3           : origin = 0x009800, length = 0x000800
   RAMLS2_3         : origin = 0x009000, length = 0x001000
   RAMLS4           : origin = 0x00A000, length = 0x000800
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

CLA_SCRATCHPAD_SIZE = 0x100;
--undef_sym=__cla_scratchpad_end
--undef_sym=__cla_scratchpad_start

MEMORY
{
   /* BEGIN is used for the "boot to SARAM" bootloader mode   */
   BEGIN            : origin = 0x000000, length = 0x000002
   BOOT_RSVD        : origin = 0x000002, length = 0x0001AF     /* Part of M0, BOOT rom will use this for stack */
   RAMM0            : origin = 0x0001B1, length = 0x00024F
   RAMM1            : origin = 0x000400, length = 0x0003F8     /* on-chip RAM block M1 */

//   RAMM1_RSVD       : origin = 0x0007F8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
   RAMD0            : origin = 0x00C000, length = 0x000800
   RAMD1            : origin = 0x00C800, length = 0x000800
   RAMLS0           : origin = 0x008000, length = 0x000800
   RAMLS1           : origin = 0x008800, length = 0x000800
   //RAMLS2           : origin = 0x009000, length = 0x000800
   //RAMLS3           : origin = 0x009800, length = 0x000800
   RAMLS2_3         : origin = 0x009000, length = 0x001000
   RAMLS4           : origin = 0x00A000, length = 0x000800
   RAMLS5           : origin = 0x00A800, length = 0x000800
   RAMLS6           : origin = 0x00B000, length = 0x000800
   RAMLS7           : origin = 0x00B800, length = 0x000800
   RAMGS0           : origin = 0x00D000, length = 0x001000
   RAMGS1           : origin = 0x00E000, length = 0x001000
   RAMGS2           : origin = 0x00F000, length = 0x001000
   RAMGS3           : origin = 0x010000, length = 0x001000
   RAMGS4           : origin = 0x011000, length = 0x001000
   RAMGS5           : origin = 0x012000, length = 0x001000
   RAMGS6           : origin = 0x013000, length = 0x001000
   RAMGS7           : origin = 0x014000, length = 0x001000
   RAMGS8           : origin = 0x015000, length = 0x001000
   RAMGS9           : origin = 0x016000, length = 0x001000
   RAMGS10          : origin = 0x017000, length = 0x001000
   RAMGS11          : origin = 0x018000, length = 0x001000
   RAMGS12          : origin = 0x019000, length = 0x001000
   RAMGS13          : origin = 0x01A000, length = 0x001000
   RAMGS14          : origin = 0x01B000, length = 0x001000
   RAMGS15          : origin = 0x01C000, length = 0x000FF8
//   RAMGS15_RSVD     : origin = 0x01CFF8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   /* Flash sectors */
   FLASH0           : origin = 0x080000, length = 0x002000	/* on-chip Flash */
   FLASH1           : origin = 0x082000, length = 0x002000	/* on-chip Flash */
   FLASH2           : origin = 0x084000, length = 0x002000	/* on-chip Flash */
   FLASH3           : origin = 0x086000, length = 0x002000	/* on-chip Flash */
   FLASH4           : origin = 0x088000, length = 0x008000	/* on-chip Flash */
   FLASH5           : origin = 0x090000, length = 0x008000	/* on-chip Flash */
   FLASH6           : origin = 0x098000, length = 0x008000	/* on-chip Flash */
   FLASH7           : origin = 0x0A0000, length = 0x008000	/* on-chip Flash */
   FLASH8           : origin = 0x0A8000, length = 0x008000	/* on-chip Flash */
   FLASH9           : origin = 0x0B0000, length = 0x008000	/* on-chip Flash */
   FLASH10          : origin = 0x0B8000, length = 0x002000	/* on-chip Flash */
   FLASH11          : origin = 0x0BA000, length = 0x002000	/* on-chip Flash */
   FLASH12          : origin = 0x0BC000, length = 0x002000	/* on-chip Flash */
   FLASH13          : origin = 0x0BE000, length = 0x002000	/* on-chip Flash */
   CPU1TOCPU2RAM    : origin = 0x03A000, length = 0x000800
   CPU2TOCPU1RAM    : origin = 0x03B000, length = 0x000800

   CPUTOCMRAM       : origin = 0x039000, length = 0x000800
   CMTOCPURAM       : origin = 0x038000, length = 0x000800

   CANA_MSG_RAM     : origin = 0x049000, length = 0x000800
   CANB_MSG_RAM     : origin = 0x04B000, length = 0x000800
   RESET           	: origin = 0x3FFFC0, length = 0x000002

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


SECTIONS
{
   codestart        : > BEGIN
   .text            : >> RAMGS0 | RAMGS1 | RAMGS2 | RAMGS3 | RAMGS4 | RAMGS5 | RAMGS6 | RAMGS7
   .cinit           :  > RAMGS4
   .switch          : >> RAMLS1
   .reset           : > RESET, TYPE = DSECT /* not used, */

	.ppdata        	: {} > RAMGS7
	.cio        	: {} > RAMGS8

   .stack           : > RAMD0
#if defined(__TI_EABI__)
   .bss             : >> RAMM1 | RAMD0 | RAMD1
   .bss:output      : >> RAMM1 | RAMD0 | RAMD1
   .init_array      : >> RAMM1 | RAMD0 | RAMD1
   .const           : >> RAMM1 | RAMD0 | RAMD1
   .data            : >> RAMM1 | RAMD0 | RAMD1
   .sysmem          : > RAMLS1
#else
   .pinit           : >> RAMM1 | RAMD0 | RAMD1
   .ebss            : >> RAMM1 | RAMD0 | RAMD1
   .econst          : >> RAMM1 | RAMD0 | RAMD1
   .esysmem         : >> RAMM1 | RAMD0 | RAMD1
#endif

   ramgs0 : > RAMGS0, type=NOINIT
   ramgs1 : > RAMGS1, type=NOINIT

   MSGRAM_CPU1_TO_CPU2 > CPU1TOCPU2RAM, type=NOINIT
   MSGRAM_CPU2_TO_CPU1 > CPU2TOCPU1RAM, type=NOINIT
   MSGRAM_CPU_TO_CM   > CPUTOCMRAM, type=NOINIT
   MSGRAM_CM_TO_CPU   > CMTOCPURAM, type=NOINIT

   dclfuncs           : > RAMLS1

    /* CLA specific sections */
   Cla1Prog         : > RAMLS2_3

   Cla1ToCpuMsgRAM  : > CLA1_MSGRAMLOW, type=NOINIT
   CpuToCla1MsgRAM  : > CLA1_MSGRAMHIGH, type=NOINIT
   Cla1DataRam      : >> RAMLS4

   /* CLA C compiler sections */
   //
   // Must be allocated to memory the CLA has write access to
   //
   CLAscratch       :
                     { *.obj(CLAscratch)
                     . += CLA_SCRATCHPAD_SIZE;
                     *.obj(CLAscratch_end) } >  RAMLS4

   .scratchpad     : > RAMLS4
   .bss_cla		    : > RAMLS4
   .const_cla	    : > RAMLS4
   cla_shared      : > RAMLS4

    .TI.ramfunc : {} > RAMGS0
   Excitation_Array : > RAMGS1

}

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

I don't have the map file of when the issue was exhibited so I can't provide it to you.

And as I explained the issue has disspeared but I don't really like things that magically disappear so I would appreciate finding an explanation.

Best regards,

Clément

0 Delaney Woodward 19 days ago in reply to Clément Letonnelier

TI__Genius 13525 points

Hi Clément,

I apologize for my delayed response. Just to verify, this is the same version of the linker cmd you were using when you saw the issue? I see no major issues with the linker cmd file.

Do you see the .word 0x7BC0 instruction showing up in the disassembly for the working version of the project? Or does the line reading into V1 have the MLSL32 instruction like the reads into other parts of the G_U structure?

Best Regards,

Delaney

0 Clément Letonnelier 13 days ago in reply to Delaney Woodward

Expert 2606 points

Hi Delaney,

No worries.

Yes this is the same linker command file.

For both versions, the dissassembly on the computer was fine.

Or you meant in the debugger ? When it was working the disassembly in the debugger was the same than the other reads.

Clément

0 Allison Nguyen 10 days ago in reply to Clément Letonnelier

TI__Mastermind 20700 points

Hi Clément,

Delaney is currently out of office and will get back to you as soon as possible when she returns next week. Appreciate your continued patience in the meantime!

Best Regards,

Allison

+1 Delaney Woodward 4 days ago in reply to Allison Nguyen

TI__Genius 13525 points

Hi Clément,

Alright, I was trying to see if the .word 0x7BC0 instruction was the cause of the issue. My thought here is that the line where V1 is written (errored) line is the only section in the disassembly that has the .word 0x7BC0 instruction and is missing the MLSL32 MR0, #16. So, I was thinking the memory got corrupted at that line somehow. But if the CCS Disassembly view has that line in the working case, it must not be the issue.

I still believe that this is a memory issue, whether it be the linker allocating something in an improper location or that your memory is corrupted at that location on your device. Unfortunately, since you can't get the issue to show up again, I don't know how to pinpoint what it is exactly. If you are able to get it to show up again, please send the errored project here so I can try to replicate it. I apologize that I don't have a more exact answer.

Best Regards,

Delaney

0 Clément Letonnelier 3 days ago in reply to Delaney Woodward

Expert 2606 points

Hi Delaney,

Yeah this is what I believe too, I was trying to find an explanation but without being able to replicate it we are definitely stuck.

Maybe the evaluation board I am using is starting to get old hehe.

Thank you for your help,

Best regards

Clément

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28386D: CLA not updating properly part of a structure