LAUNCHXL-F280049C: CLA solution, SCI ISR overruns ADC ISR MCSDK.

A work around SCI not having CLA bus or PIE interrupts: Make CLA task 1 run until it sets PIE flag or SCIB INTX data has C28x bus during CLA task 1 hardware triggers ADCC1 for mainISR().

Question: Could EPWM peripheral be assigned task 8 (background) for CLA data/address bus control? 

e.g. One task is serviced at a time until its completion. There is no nesting of tasks. However task 8 can run background processes.

I have mainISR() running CLA hardware vector task 1 (CLA_MVECT_1) trigger source (CLA_TRIGGER_ADCC1). Yet the Technical Brief and cla.h do not keep consistent numbering shown below. Also there is no disclosure in TRM, datasheet or TB that explains if PIE ADCC1 INT source must still be cleared or group ACK. The CLA task 1 ISR seems to be working but running so fast there is no LED blink rate (Hertz) and the Lab07 show startup speed (90Hz) with no motor or not being run motor enabled. The debug asp script is updating ADC values such as bus voltage 24vdc and SVM PWM writes. Setting mainISR() LED blink rate 520700Hz, still remains perpetually active.  

Below which is LSx RAM task 8 and task 1 shown above posted example TB text? Do we assume LS0 is task 1 and LS7 is task 8? Or is LS0 task 8 being the highest priority that runs constantly in the background and stated example TB text

//
// LSxRAM - Local shared RAM config
//
#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 //!< All LS RAM

It seems the ADCC1 ISR is not vectoring to CLA task 1 trigger source since it's not loaded into ~SECT_LS0 RAM (2048K). That copy from Flash to RAM should be an automatic load when the CLA trigger source is executed. At the very least when the trigger source is first enabled, auto copy Flash ISR code block to RAM for CLA assigned task memory address to access it.

1. Copy CLA code into the CLA program RAM: The source for the CLA code can initially reside in the flash or a data stream from a communications peripheral or anywhere the main CPU can access it. The debugger can also be used to load code directly to the CLA program RAM during development. CLA breakpoints have to compiled to single step the CLA setup. 

Q1: CCS debug command or use of assembler instructions?

Hi,

The CLA only has access to LSRAMs. Hence, the CLA code and data should reside in LSRAM only

Please refer to the examples in C2000ware to understand how to copy the CLA code from Flash to LSRAM

This guide would be helpful -

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

Regards,

Veena

Veena Kamath said:

The CLA only has access to LSRAMs. Hence, the CLA code and data should reside in LSRAM only

Hi Veena,

Correct and the problem being all the CLA examples have used Boot Loader RAM sections DCLR.cmd file. MCSDK has FLASH *.cmd file data code CLA1 section defined and the CLA examples copy Flash CLA (code) to RAM prior to doing CLA configuration from RAM sections area. What exactly constitutes as being CLA code: The (cmd section)? Application(software)? CLA configuration or both?

Perhaps define what word (code) is referring to in the CLA examples driver call text. To me it's all code until the application is mcopy into CLA shared memory with CPU. The ctrl_data does not seem to be in CLA memory section. How to make ctrl_data section (*.cmd) currently even mcopy(~CLA) asserted above the ctrl_data sections in LABS module where main.c resides with task_mainISR()? It looks like the MCSDK HAL.c was setup for CLA at one time then CLA call was commented out.

#pragma CODE_SECTION(task_mainISR, ".TI.ramfunc");

USER_Params userParams; //!< the user parameters for motor control and hardware board configuration
#pragma DATA_SECTION(userParams, "ctrl_data"); //"cla_shared"

volatile MOTOR_Vars_t motorVars = MOTOR_VARS_INIT;

#pragma DATA_SECTION(motorVars, "ctrl_data"); //"cla_shared"

I added the mcopy(~CLA sections) to HAL_CLAsetup() top of configuration under declarations same as CLA examples. Task1 is LABS module MPERINT1 PIE vectors into task_mainISR() and perpetually sets CLA ISR overflow flag in debug registers, GPIO decimation output never pulses. I think the motor configuration data sections are not in the CLA memory and (main.c) sets up most the data for original FLASH data section. So task1 ISR stalls not fining data in CLA memory section but does not throw other CLA memory exception flags in debug registers.

Seems we don't actually have to clear the CLA_INTx PIE flags? As the ADC clear ISR/ACK remain and CLA HW trigger is assigned ADCC1. There task1(software), task2 (data), task 3(software) is not yet a function. Is it illegal to have CLA tasks without an actual function to assert? 

Attached is the F2800x_flash_cpu_is,cmd and map files. The map address for task1_mainISR() seems to be incorrect, (0x00080004 length 462). Seem to recall seeing (TRM) that LS0_1 CLA memory should map to 0x00008000 (task1) and not 0x00080004 for .TI.ramfunction RUN ADDR = 0000a000. Perhaps the compiler is not correcting the mcopy(~CLA) sections in either *.cmd file for defined task1 vector address.  

 /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: The X49c has shared 8 LSRAMS per SPRT727A–March 2017–Revised January 2018, Pg.3 Fig.2. 

SDK Project properties processor options was set for CLA2 but the linker had --define=CLA=1 (changed =2), TRM stated to compile --support=CA2. The TRM also stated to compile any CLA debug breakpoints. Yet (C2K_CLA_SDG_v1.0) never mentions debugging type CLA2=(~stop1) or __mdebugstop1().   

By CLA code I meant the code run by the CLA core, i.e, section. .text consists of code run from the C28x core

I don't quite follow you. Could you be more precise on your question?

Regards,

Veena

Veena Kamath said:

Could you be more precise on your question?

The CLA type in the motor control SDK examples linker was set CLA type 1 X49c has CLA type 2 MCU. The other issue can you tell by the MAP files and CMD sections if task_mainISR() was actually copied into CLA shared ram address. I used the same syntax placement below (2nd code box) to do the copy of the CLA driver lib calls that should map the PIE vector for the CLA ram address and HW triggered ISR function.

The CLA examples (all) place mcopy(~CLA~ ) above CLA driverlib calls (2nd code box). Seemingly there are no specific CLA RAM sections being created for CMD for the CLA configured tasks directive [ #pragma CODE_SECTION(task_mainISR, ".TI.ramfunc") ] . The project HAL does an mcopy() too before CLA tasks setup code is called (1st code box). Is mcopy(~CLA~) (2nd code box) redundant or even needed? Did the CMD memory page 1 and sections (zips) have the correct define for CLA - RAMLS0_1 (4096) and data (RAMLS2_3 (3840) CPU shared ram address space and map file have the same load address location for 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)

The CLA examples are all created via Boot_Loader RAM CMD files versus running from Flash boot mode flash_cpu_is.cmd file memory page 1 with RAM compiled CLA tasks. Examples are confusing how the application ISR tasks get copied into CLA shared RAM from a Flash compiled application. And how does flash compile project move flash_cpu_is.cmd memory page1 task1 to (RAMLS0_1) address space, versus flash memory address space? Does it make any sense what I'm saying here? Do the two mcopy() commands differ in how the #pragma sections memory page1 addresses are being created in the Flash compile project, versus how map file shows address for task_mainISR() is not at the same RAMLS0_1 address space after mcopy?

#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

Genatco said:

The TRM also stated to compile any CLA debug breakpoints

CCS v9.3 has no idea what CLA break point is as it only has CCS break points one can set/compile in any CLA task ISR. The TRM text assumes C2000 compiler will assert the break point directive MDEBUGSTOP in the CLA task. Compiler warns CLA instructions cannot be in the same CLA task with other CLA instructions.

The CLA task with CCS break point must use __asm(" MDEBUGSTOP") compiler directive to first compile CCS break point for a given CLA task. I failed to have any idea how to use __mdebugstop(); intrinsic instead, text fails to convey what the heck it's talking about. 

Genatco said:

I have mainISR() running CLA hardware vector task 1 (CLA_MVECT_1) trigger source (CLA_TRIGGER_ADCC1)

But it really was not running in CLA memory space as noted by the MAP file address for task_mainISR(). The CLALS0_1 task RAM was assigned to the wrong page with no configured data section in page1.

CCS compiler only creates #pargma entry if it does not already exist with Sections area defined for CLA memory space. There is no CLA sections area and the task ISR now fails after creating an entry in page 0 for CLALS0_1 software task 1. Seemingly CLA page 0 program RAM memory space and sections should be created in all example projects for future task assignments. C2000 compilers do not create the CMD sections area for (mcopy()) symbols but should attempt to do so since it is a specific syntax.

The MCSDK project labs assigned CLALS0_1 into memory page 1 [#paragma( mainISR, TI.ramfunc)] contrary to F2800x49_flash_is.cmd notes not to do that.

"Page 0 is to organize program sections"

"Page 1 is organize data sections, e.g. not CLA task memory"

F2800x49c_cpu_flash_is.cmd MAP file now has the correct CLALS0_1 memory address but no defined sections area for the mcopy(~CLA~) global link exports to function.

Memory {

Page 0 :

   RAMLS0_1      : origin = 0x008000, length = 0x001000  /* CLA Software task1 */

MAP with CLA sections area.

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
PAGE 0:
RAMLS0_1 00008000 00001000 000008c8 00000738 RWIX

.TI.CLARamTask1
* 0 00008464 00000464 RUN ADDR = 00008000
00008464 00000464 is07_speed_control.obj (.TI.CLARamTask1:_task_mainISR)

Now the CLA triggered ADCC1 ISR cause an illegal interrupt operation running inside CLA memory address space! The PIE ISR vector is registered for CLA task1.

    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);