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.

[参考译文] TMS320F28P550SJ:如何在 SysConfig 中处理 LS8/LS9上的 CLA 代码。

Guru**** 2309090 points
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1520103/tms320f28p550sj-how-to-handle-cla-codes-on-ls8-ls9-in-sysconfig

器件型号:TMS320F28P550SJ
Thread 中讨论的其他器件:SysConfigC2000WARE

工具/软件:

尊敬的 champs:  

我向我们的客户询问这个问题。

用户希望在下面的 SysConfig 中将 LS8/LS9用于 CLA 程序。

但是、下面由 SysConfig 生成的存储器复制代码不正确。

它们应该与以下类似、因为从 CPU 的角度来看、LS8位于0x14000上、而不是位于0x4000上。

Memcpy ((uint32_t *)((uint32_t)&Cla1ProgRunStart +(0x10000U))、(uint32_t *)&Cla1ProgLoadStart、
(uint32_t)&Cla1ProgLoadSize);

因此、我们发现、如果代码是从 SysConfig 生成的、则 CLA 无法运行。

1.这是 SysConfig 错误吗?

如果没有、您能向我们展示如何在 SysConfig 中执行该操作吗?

2.如果 CLA 程序代码大于 LS8+LS9 (32KB)该怎么办?

也就是说、当用户代码需要从 LS8移至 RAM 时、用户如何移动代码?

Memcpy ((uint32_t *)((uint32_t)&Cla1ProgRunStart +(0x10000U))、(uint32_t *)&Cla1ProgLoadStart、
(uint32_t)&Cla1ProgLoadSize);

即从 CPU 0x14000/CLA 0x4000到 CPU 0x8000 (LS0)。

LS9 (0x17FFF)末尾和 LS0 (0x8000)开头的 CPU 角度存在这种不连续性。  

 

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 champs:

    还有一个问题、

    对于专用 CPU 使用(0x14000-0x17FFF)、可以将 LS8/LS9分配给 CPU 代码或数据使用。 对吗?

    对于 CLA 使用(0x4000-0x7FFF)、是否可以将 LS8/LS9分配给 CLA 程序或数据(CPU/CLA 共享数据)使用? 或者、它们只能用于 CLA 程序、不能用作 CLA 数据?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Wayne:

    这看起来确实是 Sysonfig 生成的代码中的一个错误、尚未添加对此特定用例的支持。 在这种情况下、最好遵循 C2000ware 示例代码(CLA_ASIN_LS8_9)并在主文件中进行这些初始化。 我将确保在未来的 C2000ware 版本中添加此内容。  

    LS8和 LS9只能选择配置为 CLA 程序存储器、而不能配置为 CLA 数据存储器、请参阅存储器映射访问:

    如果 CLA 代码大于 LS8和 LS9中可容纳的代码、则需要将程序分配给存储器的非连续部分。 以下是这方面的一个示例:

    • .cmd 文件

    RAMLS8_LS9 : origin = 0x004000, length = 0x004000 // LS8~LS9 for CLA_PROGRAM

    RAMLS0_LS1 : origin = 0x008000, length = 0x001000 // LS0~LS1 for CLA_PROGRAM

    Cla1Prog : LOAD = FLASH_BANK0,
    RUN = RAMLS8_LS9,
    LOAD_START(Cla1ProgLoadStart_LS8_9),
    RUN_START(Cla1ProgRunStart_LS8_9),
    LOAD_SIZE(Cla1ProgLoadSize_LS8_9),
    ALIGN(4)

    Cla1Prog : LOAD = FLASH_BANK0,
    RUN = RAMLS0_LS1,
    LOAD_START(Cla1ProgLoadStart_LS0_1),
    RUN_START(Cla1ProgRunStart_LS0_1),
    LOAD_SIZE(Cla1ProgLoadSize_LS0_1),
    ALIGN(4)

    • 使用.c 文件执行 memcpy

    memcpy((uint32_t *)&Cla1ProgRunStart_LS0_1, (uint32_t *)&Cla1ProgLoadStart_LS0_1,
    (uint32_t)&Cla1ProgLoadSize_LS0_1);

    memcpy((uint32_t *)((uint32_t)&Cla1ProgRunStart_LS8_9 + (0x1E000U)), (uint32_t *)&Cla1ProgLoadStart_LS8_9,
    (uint32_t)&Cla1ProgLoadSize_LS8_9);

    如果回答了所有客户问题、请支持此回答。 Slight smileμ s

    此致、

    Delaney

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Delaney:

    从下面的开始、如果用户仅使用一个函数本身且大于32KB 的 CLA 任务1、该 CLA 任务1函数是否会从 LS8 (0x4000)开始放置、然后位于0x7FFF/0x8000上? 您能否确认编译器/链接器可以将相同的函数放置在下面声明的两个 RAM 中?

    顺便说一下、我们通常使用对齐(8)、这里您有目的使用对齐(4)? 还是 align (8)也正常?

    Cla1Prog : LOAD = FLASH_BANK0,
    RUN = RAMLS8_LS9,
    LOAD_START(Cla1ProgLoadStart_LS8_9),
    RUN_START(Cla1ProgRunStart_LS8_9),
    LOAD_SIZE(Cla1ProgLoadSize_LS8_9),
    ALIGN(4)

    Cla1Prog : LOAD = FLASH_BANK0,
    RUN = RAMLS0_LS1,
    LOAD_START(Cla1ProgLoadStart_LS0_1),
    RUN_START(Cla1ProgRunStart_LS0_1),
    LOAD_SIZE(Cla1ProgLoadSize_LS0_1),
    ALIGN(4)

    2. From below, the offset for LS8_9 is 0x1E000 rather than 0x10000?

    memcpy((uint32_t *)((uint32_t)&Cla1ProgRunStart_LS8_9 + (0x1E000U)), (uint32_t *)&Cla1ProgLoadStart_LS8_9,
    (uint32_t)&Cla1ProgLoadSize_LS8_9);

    3. Is .const_cla viewed as CLA program or CLA data? Can .const_cla be placed on LS8/LS9? We are asking this because it requires memory copy. We are confused if .const_cla follows the same way as Cla1Prog if they are placed on LS8/LS9?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Wayne:

    我明天会回复您。

    此致、

    Delaney

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Wayne:

    很抱歉耽误你的时间。  

    从下面开始、如果用户仅使用一个函数本身大于32KB 的 CLA 任务1、该 CLA 任务1函数是否会从 LS8 (0x4000)开始放置、然后位于0x7FFF/0x8000之间? 您能否确认编译器/链接器可以将相同的函数放在下面声明的两个 RAM 之间?

    是的、如果将 LS8和 LS9组合到存储器{}的一个范围内(如示例所示)、则可以将大于32KB 的任务分配给存储器范围。

    不过在这种情况下、如果可能、我建议将代码拆分为不同的任务(如果未使用其他任务)。 您可以在另一个任务中从软件手动触发任务(在此处查看更多信息:  4.常见问题解答—C2000Tm CLA 软件指南 )。

    顺便 说一下、我们通常使用 align (8)、这里您使用 align (4)的目的是什么? 还是 align (8)也可以?

    我 不知道链接器如何使用 align 属性太多、 在 汇编语言工具指南中应该有更多信息。但是、C2000ware 中 CLA 的示例链接器 cmd 文件使用 align (4)、因此我建议匹配此文件是安全的。

    2. 从下面开始、LS8_9的偏移是0x1E000、而不是0x10000?

    抱歉、我应该提到我提供的示例是专门针对 F28P65x 的示例(由于存储器映射、该示例需要0x1E000偏移)。 对于 F28P55x、您可以像在 C2000ware 示例中一样将此值更改为0x10000。

    3. const_cla 是被视为 CLA 程序还是 CLA 数据? 可以 将.const_cla 放置在 LS8/LS9上吗? 我们之所以问这个问题、是因为它需要存储器副本。 如果 .const_cla 与 Cla1Prog 遵循相同的方式(如果将它们放置在 LS8/LS9上?
    上)、那么我们会感到困惑

    CONST_CLA 视为 CLA 的数据存储器。 链接器 cmd 中除 Cla1Prog 之外的每个 CLA 分配都是数据存储器。 因此、不可以将 CONST_CLA 放置在 LS8/LS9中、因为无法将这些变量分配为 CLA 数据存储器。 该函数需要放置在 LS0-LS7中、并使用不需要任何偏移的 memcpy。

    此致、

    Delaney

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Delaney:

    "但在这种情况下、如果可能的话、如果其他任务未使用、我建议将代码拆分为不同的任务。"

    您意味着用户可以通过软件调用 task2和任务1结束来将长任务1分离到任务1和任务1中?

    原因是编译器可以将它们分开并单独放置、对吧?

    还是其他原因?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Wayne:

    是的、在这种情况下、编译器会制造两个不同的符号、因此链接器 在 分配存储器的方式方面具有更大的灵活性。 它也更模块化、因此是更好的编码实践。

    此致、

    Delaney