TMS320F280049C: GPIO output could not be toggled when used in .cla file

Rayna,

Check if there is anything on the board holding the pin in a specific state or different connection.   On the launchpad for example, there are some pins connected via resistors to the FSI. This is described in the launchpad users guide. 

Can the C28x toggle the pin?  (if you don't assign master core to the CLA of course).  

-Lori

Hi Lori,

Customer tests this using control card, which should not be caused by the board.

And the C28x could toggle the GPIO22 pin.

Best Regards

Rayna

Rayna,

I searched through the F28004x TRM for GPIO22.  Was this point taken care of?  I'm assuming yes, since the c28x can toggle the pin?

• Analog mode select for GPIO22: GPIO22 and GPIO23 are in a special analog mode at reset, and must be configured for GPIO use by disabling DC-DC and clearing their bits in GPAAMSEL.

Rayna Wang said:

And the C28x could toggle the GPIO22 pin.

• Was the same code used on the C28x (HWREG vs driverlib function)? 
• I'm assuming the value of GPIO_PROFILING1_CLEAR is correct, but I can't tell from the code provided. 

Rayna Wang said:

HWREG(GPIODATA_BASE + GPIO_O_GPACLEAR ) = GPIO_PROFILING1_CLEAR; //always stop here, after click "RUN" button.

I don't see a reason why the CLA would halt here. 

• Can you share a screenshot of the CLA disassembly corresponding to this line?
• Does the disassembly show the MPC is at this line, or at a MSTOP?

-Lori

Hi Lori,

Thanks a lot for your help! Please see the video below for the demo of the issue:

Summary: I am able to toggle GPIO22 with code setProfilingGPIO() & resetProfilingGPIO(), but can not toggle GPIO22 with the same code in CLA TASK.

Xiaoquan

Summary: I am able to toggle GPIO22 with code setProfilingGPIO() & resetProfilingGPIO() in .c file, but can not toggle GPIO22 with the same code in CLA TASK.

Xiaoquan,

Thank you for the video.  I tried to reproduce the issue on my F28004x launchpad, but have not been successful so something else is going on. 

In your video, when you tried to single step the CLA, CCS was asking for where the source to the file was located.  I believe it is part of driverlib.  Just click "locate file" and browse to that directory and CCS will be able to display the source. 

Here are my steps for trying to reproduce the issue:

1) Started with the CLAMath sin example project (C:\ti\c2000\C2000Ware_3_03_00_00\libraries\math\CLAmath\c28\examples\sin) Selected the build config for F28004x RAM.

2) Added this code to the init of the project:

    GPIO_setAnalogMode(22,GPIO_ANALOG_DISABLED);
    GPIO_setDirectionMode(22,GPIO_DIR_MODE_OUT);
    GPIO_setQualificationMode(22,GPIO_QUAL_SYNC);
    GPIO_setPinConfig(GPIO_22_GPIO22);
    GPIO_setMasterCore(22, GPIO_CORE_CPU1_CLA1);

3) Added #include "driverlib" to the .cla file

4) Added CLEAR/SET around the call to the sin function

//
// Task 1 : Calculate sin(X)
//
__attribute__((interrupt)) void Cla1Task1(void)
{
    //__mdebugstop();
    HWREG(GPIODATA_BASE + GPIO_O_GPASET ) = 0x00400000UL;
    fResult1 = CLAsin(fVal);
    HWREG(GPIODATA_BASE + GPIO_O_GPACLEAR ) = 0x00400000UL;
}
__attribute__((interrupt)) void Cla1Task2(void)
{

    HWREG(GPIODATA_BASE + GPIO_O_GPASET ) = 0x00400000UL;
    // Test inline function
    // Project must use --opt_level= 0 or higher for inline to occur
    //
    //__mdebugstop();
    fResult2 = CLAsin_inline(fVal);
    HWREG(GPIODATA_BASE + GPIO_O_GPACLEAR ) = 0x00400000UL;

}

5)  Observed:

The C28x checks the answers coming from the CLA and all pass. 

The CLA code halts at a MSTOP.  Note: Optimization may make the source code look a bit off from where the CLA stopped.  I can see that it is at the MSTOP in the disassembly window even if optimization is turned on.  View --> Disassembly

I monitored GPIO on my scope and toggles. 

Thanks, Lori. Is there any other workaround to toggle GPIO inside CLA TASK? 

I tried to use "GPIO_writePin(22,1);" &  "GPIO_writePin(22,0);" . They successfully toggled GPIO22 from .c file, but still failed in toggling when placed in CLA TASK. 

Xiaoquan,

I still think something else is going on.  I had no issue toggling the pin on my hardware in the CLA task.  You can try reproducing my experiment to rule out a hardware issue.

On the code causing the problem:

Can you try debugging the CLA code by stepping through it?  

Also can you take a screenshot of the disassembly where the HWREG write happens?  

Did adding the two lines of code to the CLA task have an impact such as increase the size of the task?  Does the task still fit in the same RAM block? 

-Lori