[参考译文] LAUNCHXL-F280049C：CLA 解决方案、SCI ISR 超过 ADC ISR MCSDK。

针对 SCI 没有 CLA 总线或 PIE 中断的工作：使 CLA 任务1运行直到它设置 PIE 标志或 SCIB INTX 数据在 CLA 任务1期间具有 C28x 总线硬件触发针对 mainISR()的 ADCC1。

问题： 是否可以为 ePWM 外设分配任务8 (后台)以进行 CLA 数据/地址总线控制？  

例如 、一次处理一个任务、直至其完成。 没有任务嵌套。 但是、任务8可以运行后台进程。

我有一个运行 CLA 硬件矢量任务1 (CLA_MVECT_1)触发源(CLA_TRIGGER_ADCC1)的 mainISR ()。 但是、技术简介和 cla.h 的编号不一致、如下所示。 此外、TRM、数据表或 TB 中没有披露是否仍必须清除 PIE ADCC1 INT 源或组 ACK。 CLA 任务1 ISR 似乎正常工作、但运行得太快、没有 LED 闪烁速率(赫兹)、Lab07显示了在没有电机或未启用运行电机的情况下的启动速度(90Hz)。 debug ASP 脚本正在更新 ADC 值、例如总线电压24V 直流和 SVM PWM 写入。 设置 mainISR() LED 闪烁速率520700Hz，仍保持永久活动状态。   

下面哪个是上面显示的 LSx RAM 任务8和任务1发布的示例 TB 文本？ 我们是否假设 LS0是任务1、LS7是任务8？ 或者 LS0任务8是在后台持续运行的最高优先级、并声明了示例 TB 文本

//
// LSxRAM -本地共享 RAM 配置
//
#define MEMCFG_Sect_LS0 0x01000001U //！< LS0 RAM
#define MEMCFG_Sect_LS1 0x01000002U //！< LS1 RAM
#define MEMCFG_Sect_LS2 0x01000004U //！< LS2 RAM
#define MEMCFG_Sect_LS3 0x01000008U //！< LS3 RAM
#define MEMCFG_Sect_LS4 0x01000010U //！< LS4 RAM
#define MEMCFG_Sect_LS5 0x01000020U //！< LS5 RAM
#define MEMCFG_Sect_LS6 0x01000040U //！< LS6 RAM
#define MEMCFG_Sect_LS7 0x01000080U //！< LS7 RAM
#define MEMCFG_Sect_LSX_ALL 0x010000FFU //！<所有 LS RAM

由于 ADCC1 ISR 未加载到~sect_LS0 RAM (2048K)中、因此 ADCC1 ISR 似乎不会引导至 CLA 任务1触发源。 当 CLA 触发源被执行时、从闪存到 RAM 的复制应该是一个自动加载。 至少在首次启用触发源时、自动将闪存 ISR 代码块复制到 RAM 中、以便 CLA 分配的任务 存储器地址进行访问。

1.将 CLA 代码复制到 CLA 程序 RAM 中：CLA 代码的源最初可以驻留在闪存中或来自通信外设或主 CPU 可以访问的任何位置的数据流中。 在开发过程中、调试器还可用于将代码直接加载到 CLA 程序 RAM 中。 CLA 断点必须编译为 CLA 设置的单步执行。  

Q1： CCS 调试命令还是使用汇编器指令？

您好！

CLA 只能访问 LSRAM。 因此、CLA 代码和数据应该只驻留在 LSRAM 中

请参阅 C2000ware 中的示例、了解如何将 CLA 代码从闪存复制到 LSRAM

本指南将会有所帮助-

https://software-dl.ti.com/C2000/docs/cla_software_dev_guide/index.html

此致、

Veena

[引用 userid="128297" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1166100/launchxl-f280049c-cla-solution-sci-isr-overruns-adc-isr-mcsdk/4387051 #4387051"]CLA 仅有权访问 LRAM。 因此、CLA 代码和数据应该只驻留在 LSRAM 中

您好、Veena、

更正了、问题是所有 CLA 示例都使用了引导加载程序 RAM 部分 DCLR.cmd 文件。 MCSDK 定义了闪存*。cmd 文件数据代码 CLA1部分、CLA 示例在从 RAM 部分区域执行 CLA 配置之前将闪存 CLA (代码)复制到 RAM 中。 什么确切地构成 CLA 代码：(cmd 段)？ 应用(软件)？ CLA 配置还是两者都是？

也许在 CLA 示例驱动程序调用文本中定义所指的字(代码)。 在我看来、这是所有代码、直到应用程序与 CPU 被 mcopy 到 CLA 共享存储器中。 CTRL_DATA 似乎不在 CLA 存储器部分中。 如何使 ctrl_data 段(*。cmd)当前甚至在 main.c 与 task_mainISR ()一起驻留的实验模块中的 ctrl_data 段上方断言 mcopy (~CLA)？ 看起来、MCSDK HAL.c 是为 CLA 设置的、然后 CLA 调用被注释掉。

#pragma CODE_SECTION (task_mainISR、".TI.ramfunc")；

USER_PARAMS userParams；//！<电机控制 和硬件板配置的用户参数
#pragma DATA_SECTION (userParams、"Ctrl_data")；//"CLA_shared"

volatile motor_Vars_t motorVars = motor_Vars_init；

#pragma DATA_SECTION (motorVars、"Ctrl_data")；//"CLA_shared"

我在 与 CLA 示例相同的声明下将 mcopy (~CLA 段)添加到 HAL_CLAsetup（)配置顶部。 任务1是实验模块 MPERINT1 PIE 向量进入 task_mainISR()并永久设置调试寄存器中的 CLA ISR 溢出标志、GPIO 抽取输出从不脉冲。 我认为电机配置数据部分不在 CLA 存储器中、并且(main.c)为原始闪存数据部分设置了大多数数据。 因此、Task1 ISR 会停止在 CLA 存储器部分中查找数据、但不会在调试寄存器中抛出其他 CLA 存储器异常标志。

我们似乎不必清除 CLA_INTx PIE 标志？ 当 ADC 清除 ISR/ACK 保持且 CLA 硬件触发器被分配 ADCC1时。 任务1 (软件)、任务2 (数据)、任务3 (软件)尚不是一个函数。 如果 CLA 任务没有实际函数来置为有效、这是否违法？  

附加的是 F2800x_flash_cpu_is、cmd 和映射文件。 Task1_mainISR()的映射地址似乎不正确(0x00080004长度462)。 似乎还记得看到(TRM)、对于.TI.ramfunction run ADDR = 0000a000、LS0_1 CLA 存储器应该映射到0x00008000 (任务1)而不是0x00080004。  对于定义的 Task1矢量地址、编译器也许不会校正*。cmd 文件中的 mcopy (~CLA)段。   

 /cfs-file/__key/communityserver-discussions-components-files/171/f28004x_5F00_flash_5F00_cpu_5F00_is.zip

/cfs-file/__key/communityserver-discussions-components-files/171/is07_5F00_speed_5F00_control.zip

BTW：X49c 已按照  SPRT727A–2017年3月–2018年1月修订版共享8个 LSRAMS、PG.3图2。  

SDK 项目属性处理器选项是为 CLA2设置的、但链接器具有--define=cla=1 (更改=2)、TRM 表示编译--support=CA2。 TRM 还声明了编译任何 CLA 调试断点。 然而(C2K_CLA_SDG_v1.0)从未提及调试类型 CLA2=(~stop1)或__mdebugstop1 ()。    

由 CLA 代码执行、我指的是由 CLA 内核、i.e、段运行的代码。 .text 由 从 C28x 内核运行的代码组成

我不太关注您。 您能更准确地回答您的问题吗？

此致、

Veena

[引用 userid="128297" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1166100/launchxl-f280049c-cla-solution-sci-isr-overruns-adc-isr-mcsdk/4389167 #4389167"]您能否更准确地回答您的问题？

电机控制 SDK 示例链接器中的 CLA 类型已设置 CLA 类型1 X49c 具有 CLA 类型2 MCU。 另一个问题是，映射文件和 CMD 段能否分辨 Task_mainISR()是否实际复制到 CLA 共享 RAM 地址中。 我在下面使用了相同的语法放置(第2个代码框)来执行 CLA 驱动程序库调用的副本、这些调用应该映射 CLA RAM 地址和硬件触发 ISR 函数的 PIE 矢量。

CLA 示例(全部)将 mcopy(~CLA~)放置在 CLA driverlib 调用之上(第2个代码框)。 似乎没有为 CLA 已配置任务指令的 CMD 创建特定的 CLA RAM 段[#pragma CODE_SECTION (task_mainISR、".TI.ramfunc")]。 项目 HAL 在 CLA 任务设置代码被调用(第一个代码框)之前也会执行 mcopy()。 mcopy (~CLA~) (第二个代码框)是冗余的还是甚至需要的？ CMD 存储器页1和段(zips)是否具有 CLA 的正确定义- RAMLS0_1 (4096)和数据(RAMLS2_3 (3840) CPU 共享 RAM 地址空间和映射文件具有与 task_mainISR ()相同的加载地址位置？  

#ifdef _FLASH
//
// Copy time critical code and flash setup code to RAM. This includes the
// following functions: InitFlash();
//
// The RamfuncsLoadStart, RamfuncsLoadSize, and RamfuncsRunStart symbols
// are created by the linker. Refer to the device .cmd file.
//
memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);
#endif

//f28004x_flash_cpu_is.cmd
PAGE 1 :
   BOOT_RSVD        : origin = 0x000002, length = 0x0000F3      /* Part of M0, BOOT rom will use this for stack */
   RAMM0           	: origin = 0x0000F5, length = 0x00030B
   RAMM1           	: origin = 0x000400, length = 0x000400

/* CLA1             : origin = 0x001400, length = 0x000080 */  /* Defined in header cmd file */

   RAMGS0_A         : origin = 0x00C000, length = 0x002000

   RAMLS0_1         : origin = 0x008000, length = 0x001000		/* Can't be used, reserved for FAST object */
   RAMLS2_3         : origin = 0x009100, length = 0x000F00		/* */

   CLA1MSGRAMLOW    : origin = 0x001480, length = 0x000080
   CLA1MSGRAMHIGH   : origin = 0x001500, length = 0x000080

}

// _control.map shows a different load address than RAMLS0_1 CLA page1 memory space 

.TI.ramfunc 
*          0    00080004    00000598     RUN ADDR = 0000a000
                  00080004    00000468     is07_speed_control.obj (.TI.ramfunc:_task_mainISR)

CLA 示例都是通过 Boot_Loader RAM CMD 文件创建的、而不是通过闪存引导模式 flash_cpu_is．cmd 文件存储器第1页运行、其中包含 RAM 编译的 CLA 任务。 示例令人困惑的是应用 ISR 任务是如何从闪存编译的应用程序复制到 CLA 共享 RAM 中的。 闪存编译工程如何 将 FLASH_CPU_S.cmd MEMORY page1任务1移动到 (RAMLS0_1)地址空间、而不是闪存存储器地址空间？ 我在这里说什么是有道理的吗？ 两条 mcopy()命令在如何在闪存编译工程中创建#pragma SECTIONS MEMORY page1地址方面是否不同？与映射文件显示 TASK_mainISR()的地址在 mcopy 之后不在相同的 RAMLS0_1地址空间中的区别？

 

#ifdef CLA
void HAL_setupCLA(HAL_Handle handle)
{
    HAL_Obj  *obj = (HAL_Obj *)handle;
    uint32_t tmp_vec;

    //
    // Copy the program and constants from FLASH to RAM before configuring
    // the CLA
    //
#if defined(_FLASH)
    memcpy((uint32_t *)&Cla1ProgRunStart, (uint32_t *)&Cla1ProgLoadStart, (uint32_t)&Cla1ProgLoadSize );
    memcpy((uint32_t *)&Cla1ConstRunStart, (uint32_t *)&Cla1ConstLoadStart, (uint32_t)&Cla1ConstLoadSize );
#endif //defined(_FLASH)

    // configure LS memory through LSxMSEL register to allow sharing between CPU and CLA
    MemCfg_setLSRAMMasterSel(MEMCFG_SECT_LS0, MEMCFG_LSRAMMASTER_CPU_CLA1);
    MemCfg_setLSRAMMasterSel(MEMCFG_SECT_LS1, MEMCFG_LSRAMMASTER_CPU_CLA1);
    MemCfg_setLSRAMMasterSel(MEMCFG_SECT_LS2, MEMCFG_LSRAMMASTER_CPU_CLA1);


    // configure what memory is for CLA program through the LSxCLAPGM register
    MemCfg_setCLAMemType(MEMCFG_SECT_LS0, MEMCFG_CLA_MEM_PROGRAM);
    MemCfg_setCLAMemType(MEMCFG_SECT_LS1, MEMCFG_CLA_MEM_DATA);//MEM_DATA
    MemCfg_setCLAMemType(MEMCFG_SECT_LS2, MEMCFG_CLA_MEM_PROGRAM);

    //
    // Suppressing #770-D conversion from pointer to smaller integer
    // The CLA address range is 16 bits so the addresses passed to the MVECT
    // registers will be in the lower 64KW address space. Turn the warning
    // back on after the MVECTs are assigned addresses
    //
    #pragma diag_suppress=770

    tmp_vec = (uint32_t)(&task_mainISR);
    CLA_mapTaskVector(obj->claHandle, CLA_MVECT_1, (uint16_t)tmp_vec);

    CLA_enableTasks(obj->claHandle, CLA_TASKFLAG_1);//CLA_TASKFLAG_ALL
    CLA_clearTaskFlags(obj->claHandle, CLA_TASKFLAG_ALL);

    //CLA_enableBackgroundTask(obj->claHandle);

    /* Enable this trigger after ADCC1 enabled */
    CLA_disableHardwareTrigger(obj->claHandle);

    //tmp_vec = (uint32_t)(&cla_EST_run_BackgroundTask);//task_mainISR
    //CLA_mapBackgroundTaskVector(obj->claHandle, (uint16_t)tmp_vec);

    CLA_setTriggerSource(CLA_TASK_1, CLA_TRIGGER_ADCC1);
    //CLA_setTriggerSource(CLA_TASK_2, CLA_TRIGGER_SOFTWARE);
    //CLA_setTriggerSource(CLA_TASK_3, CLA_TRIGGER_SOFTWARE);

	#pragma diag_warning=770

    return;
} // end of HAL_setupCLA() function
#endif

[引用 userid="48581" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1166100/launchxl-f280049c-cla-solution-sci-isr-overruns-adc-isr-mcsdk/4387942 #4387942"] TRM 还声明编译任何 CLA 调试断点

CCS v9.3不知道什么是 CLA 断点、因为它只有 CCS 断点、用户可以在任何 CLA 任务 ISR 中设置/编译。 TRM 文本假设 C2000编译器将在 CLA 任务中将断言断点指令 MDEBUGSTOP。 编译器警告 CLA 指令不能与其他 CLA 指令处于同一 CLA 任务中。

具有 CCS 断点的 CLA 任务必须使用__asm (" MDEBUGSTOP ")编译器指令来为给定的 CLA 任务首先编译 CCS 断点。 我不知道如何使用__mdebugstop()；相反，内在函数文本无法传达它所谈论的内容。  

[引用 userid="48581" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1166100/launchxl-f280049c-cla-solution-sci-isr-overruns-adc-isr-mcsdk/4386639 #4386639"]我有运行 CLA 硬件矢量任务1 (CLA_MVECT_1)触发源(CLA_TRIGGER_ADCC1)的 mainISR ()[/QUERPLET]

但它实际上并不像 task_mainISR()的映射文件地址所指出的那样在 CLA 存储器空间中运行。 CLALS0_1任务 RAM 分配给了错误的页面、第1页中没有配置数据部分。

CCS 编译器仅在没有为 CLA 存储器空间定义的段区域时创建#pargma 条目。 没有 CLA 段区域、任务 ISR 现在在 CLALS0_1软件任务1的第0页中创建一个条目后失败。 似乎 CLA PAGE 0程序 RAM 存储器空间和段应该在所有示例项目中为未来任务分配创建。 C2000编译器不会为(mcopy())符号创建 CMD 段区域，但应尝试创建该区域，因为它是特定的语法。

与 F2800x49_flash_is.cmd 相反、MCSDK 项目实验将 CLALS0_1分配到内存页1 [#paragma (mainISR、TI.ramfunc)]中。

"第0页用于组织程序段"

"第1页是组织数据段、例如、不是 CLA 任务内存"

F2800x49c_cpu_flash_is.cmd 映射文件现在具有正确的 CLALS0_1存储器地址、但 mcopy (~CLA~)全局链接导出为函数时未定义段区域。

内存｛

第0页：

  RAMLS0_1   ：origin = 0x008000、length = 0x001000 // CLA Software Task1 */

使用 CLA 段区域映射。

名称源长度使用未使用的属性填充
------------ ---- ------ ---- ---- --------
第0页：
RAMLS0_1 00008000 00001000 000008c8 00000738 RWIX

.TI.CLARamTask1.
* 0 00008464 00000464运行 ADDR = 00008000
00008464 00000464 is07_speed_control.obj (.TI.CLARamTask1：_task_mainISR)

现在 CLA 触发的 ADCC1 ISR 会导致在 CLA 存储器地址空间内运行非法中断操作！ 为 CLA 任务1注册 PIE ISR 矢量。

    EALLOW;

    PieVectTable.ADCC1_INT = &task_mainISR; //CLA1_1_INT

    EDIS;
    
    // clear the ADCC1 interrupt flag
    ADC_clearInterruptStatus(obj->adcHandle[2], ADC_INT_NUMBER1);

    // Acknowledge interrupt from PIE group 1
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP1);

    // set up trigger source for CLA task 1
    // clear the ADCA interrupt flag
    CLA_setTriggerSource(CLA_TASK_1, CLA_TRIGGER_ADCC1);

    // enable the ADCC1[2] interrupts, ADCA1[0]
    ADC_enableInterrupt(obj->adcHandle[2], ADC_INT_NUMBER1);

    // enable ADCA4 PIE interrupt associated with ADC interrupts
    Interrupt_enable(INT_ADCC1);

    // enable the cpu interrupt for ADC interrupts
    Interrupt_enableInCPU(INTERRUPT_CPU_INT1);

    // enable cpu interrupts for CLA
    Interrupt_enableInCPU(INTERRUPT_CPU_INT11);
    Interrupt_enableInCPU(INTERRUPT_CPU_INT12);