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.

TMS320F28P650DK: The CLA is not working when assign Cla1Prog to RAMLS8_CLA or RAMLS9_CLA

Part Number: TMS320F28P650DK
Other Parts Discussed in Thread: C2000WARE

Dear expert,

I have a TMS320F28P65X controlCARD. I am testing the  example for the cla_ex4_pwm_control and build it in CPU1_FALSH. Everything is work fine, but when I assign Cla1Prog from RAMLS0 to RAMLS8_CLA or RAMLS9_CLA, the CLA is not working. And I trace the SW, I found the memcpy function in board.c is not working properly. There are a lot of date lost.  Could you help to chek what's the problem ?

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
MEMORY
{
BEGIN : origin = 0x080000, length = 0x000002 // Update the codestart location as needed
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 = 0x000400
RAMD0 : origin = 0x00C000, length = 0x002000
RAMD1 : origin = 0x00E000, length = 0x002000
RAMD2 : origin = 0x01A000, length = 0x002000 // Can be mapped to either CPU1 or CPU2. When configured to CPU2, use the address 0x8000. User should comment/uncomment based on core selection
RAMD3 : origin = 0x01C000, length = 0x002000 // Can be mapped to either CPU1 or CPU2. When configured to CPU2, use the address 0xA000. User should comment/uncomment based on core selection
RAMD4 : origin = 0x01E000, length = 0x002000 // Can be mapped to either CPU1 or CPU2. When configured to CPU2, use the address 0xC000. User should comment/uncomment based on core selection
RAMD5 : origin = 0x020000, length = 0x002000 // Can be mapped to either CPU1 or CPU2. When configured to CPU2, use the address 0xE000. User should comment/uncomment based on core selection
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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/**
* These arguments were used when this file was generated. They will be automatically applied on subsequent loads
* via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
* @cliArgs --device "F28P65x" --package "256ZEJ" --part "F28P65x_256ZEJ" --context "CPU1" --product "C2000WARE@5.01.00.00"
* @versions {"tool":"1.18.0+3266"}
*/
/**
* Import the modules used in this configuration.
*/
const cla = scripting.addModule("/driverlib/cla.js", {}, false);
const cla1 = cla.addInstance();
const memcfg = scripting.addModule("/driverlib/memcfg.js");
/**
* Write custom configuration values to the imported modules.
*/
cla1.$name = "myCLA0";
cla1.cpuint_CLA_TASK_1 = false;
cla1.cpuint_CLA_TASK_2 = false;
cla1.cpuint_CLA_TASK_3 = false;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Cla1Prog is RAMLS0.

Cla1Prog is RAMLS8_CLA.

  • We don't have Cla1Prog  setting for RAMLS8 and RAMLS9 as these are always fixed to be program memory for CLA (can not use as data).  Also please note that memcpy is done by CPU and the address for LS8 and LS9 RAM for CPU is different. Please see below snapshot from Memory Map table in device datasheet.

    Regards,

    Vivek Singh

  • Hi Vivek,

    In the datasheet, LS8 and LS9 can be used as CLAProg.  But it's not working.

    Best Regads,

    Ryan Hung

  • Hi Vivek,

        I used F28P65 build configure "CPU1_RAM" to test demo code cla_ex4_pwm_control. I can't make  CLA work when assign Cla1Prog to RAMLS8_CLA nor RAMLS9_CLA. From memory dump, it looks like CLA program code doesn't be loaded to LS8/LS9. 

    Can you please double confirm If f28p65 does support LS8/LS9 to be CLA Program RAM or just typo of datasheet? If f28p65 does support, is any wrong in SDK or something else?

    Regards

    Andre

     

  • It is supported but CLA code into LS8 and LS9 need to be loaded at CPU address map and run from CLA address map. I am checking if we have any example for this. Will get back in 1-2 days.

    Vivek Singh

  • Hi,

    In latest C200Ware, we have released an example for this use case - cla_asin_ls8_9

    Below is what it has for memcpy - 

      memcpy((uint32_t *)(&Cla1ProgRunStart + 0x1E000), (uint32_t *)&Cla1ProgLoadStart,
    (uint32_t)&Cla1ProgLoadSize);

    Hope this helps.

    Regards,

    Vivek Singh

  • Vivek,

       Thanks.  Import project manually from <C2000Ware>/driverlib/f28p65x/examples/c28x/cla/

    The Resource Explorer doesn't show this project that why we did not find it at first moment.

    The project can be imported manually. Will we fix this in next release?

    Regards

    Andre

  • Dear Vivek,

    I had checked cla_asin_ls8_9.  The CLA is still not workiong when run in the flash mode.

    Best regards,

    Ryan Hung

  • Vivek,

        This demo project only work in RAM mode.  I set breakpoint  at line   MemCfg_initSections(MEMCFG_SECT_MSGCLA1TOCPU);

    RAM mode.

    Flash mode.

    Device have to be reset before mode switch to clear LS8 content. 

    The memcpy() function in Flash mode doesn't work. Security? or anything missing?

    Regards

    Andre

  • Ok, we'll check this and get back to you in 1-2 days.

  • Hi,

    Can you replace the memcpy function call in the code like below and try. 

    memcpy((uint32_t *)(&Cla1ProgRunStart + (0x1E000/2)), (uint32_t *)&Cla1ProgLoadStart, (uint32_t)&Cla1ProgLoadSize);

    Vivek Singh

  • Vivek,

          Changing CLA run address from (uint32_t *)(&Cla1ProgRunStart + (0x1E000)) to (uint32_t *)(&Cla1ProgRunStart + (0x1E000/2)) works.

    However I have question, &Cla1ProgRunStart + (0x1E000) should be 0x22000 which is start address of LS8. This 0x22000 is LS8 address before memory remapping. Why do we need to divide the offset 0x1E000?

    Regards

    Andre

  • Vivek,

         More input, Changing  memcpy((uint32_t *)(0x22000), (uint32_t *)&Cla1ProgLoadStart, (uint32_t)&Cla1ProgLoadSize); also works.

    Looks like compiler issue to generate wrong address &Cla1ProgRunStart? Can you please double confirm?

    Regards

    Andre

  • Hi,

    Cla1ProgRunStart is 0x4000 because that is CLA address for that memory where as for copy we need to use CPU address which is 0x22000 (0x4000 + 0x1E000). That is why we have to add 0x1E000 to the run address.  This is not compiler issue.

    Vivek Singh

  • --- Making update to one of the query which was not answered earlier. 

    Hi,

    However I have question, &Cla1ProgRunStart + (0x1E000) should be 0x22000 which is start address of LS8. This 0x22000 is LS8 address before memory remapping. Why do we need to divide the offset 0x1E000?

    It's because when we add something to pointer, it will be adding the multiple of pointer size, hence in the error case, it was adding double the address value (ie 2x1E000). Hence we replaced the value to 1E000/2. 

    Below is what we’ll have in updated example with typecasting for the offset so that it adds correct offset.

         memcpy((uint32_t *)((uint32_t)&Cla1ProgRunStart + (0x1E000U)), (uint32_t *)&Cla1ProgLoadStart,

               (uint32_t)&Cla1ProgLoadSize);