- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Noted issue with CLA type GPIO in CLA task ISR: LAUNCHXL-F280049C: CLA2 type GPIO toggle in task of ISR - C2000 microcontrollers forum - C2000
︎ microcontrollers - TI E2E support forums
Hello,
Reading through various Technical Brief and datasheet text, it seems slower SCI TXD interrupt span (30ms) can be assigned CLA task (8) and Instaspin 150µs main_ISR() to highest priority task (1). Being new to C2000 MCU family had not read though CLA text but noted MCSDK HAL can enable CLA for EPWM module. Seemingly slower SCI interrupt being task 8 can free CPU time for C28x bus peripherals by EPWM module enabled for CLA bus structure (data sheet Fig.8-2) and TB Fig.1.
Q1: Does SCI data remain on the C28x bus, if not why was it left out CLA data bus?
Q2: Can SCI peripheral IRQ assert CLA interrupts, e.g. datasheet Fig.8-2 being an offloaded IRQ task (8) of PIE controller?
The F28004x features a new Type 2 CLA which has the option of running the lowest priority task (Task 8) as a background task. Once triggered, it runs continuously until it is terminated or reset by the CLA or MCU. The remaining tasks (Task 1 through Task 7, in priority order) can interrupt the background task when they are triggered. If needed, portions of the background task can be made uninterruptible. Some uses of the background task include running continuous functions, such as communications and clean-up routines. The background task is enabled by setting the BGEN bit in the MCTRLBGRND register. The Task 8 interrupt vector is then loaded from the MVECTBGRND register rather than the MVECT8 register. When the background task is interrupted, the branch return address is saved to the MVECTBGRNDACTIVE register, and the address is then loaded back to the MPC when execution continues.
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)
