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.

TMS320F28P650DK: Critical bug (?)/CPU crash on C2000/ CLA1 GPIO code

Part Number: TMS320F28P650DK
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Hi,

I have encountered a critical compiler (?) bug, where an attempt to call GPIO_writePin() from within CLA1 interrupt code causes the entire CPU to hang or otherwise execution seems to be lost in space.

Description

Trying set a GPIO pin, properly configured to be under CLA1 control, using the library GPIO_writePin() function called from within __interrupt void Cla1Task1 ( void ).
The CPU seems to stop running proper code altogether, interrupts no longer happening etc.

Investigating the crash, I have isolated the issue to the following line in GPIO_writePin():

pinMask = (uint32_t)1U << (pin % 32U);

Specifically, it is the "<<" operator on a variable that causes the crash. Changing to 

pinMask = (uint32_t)1U << (9);

solves the issue.

Further Information

Using a cut&pasted my_GPIO_writePin() function in the .CLA file, I have changed the line to use a lookup table

static const uint32_t bitmap[32]={1<<0,
1<<1,
1<<2, ...
 1U<<31};

:
:

 pinMask =  bitmap[pin%32];

And everything works as expected.

Calling GPIO_writePin() from the CPU (not CLA1) code always works as expected.

As I have found a workaround, I am submitting this issue as a bug report or otherwise for your analysis or to point me to where I have missed something.

Thank You,
-Alon

  • Hi Alon,

    Thanks for sharing your feedback. Can you try to follow the steps detailed in this thread: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/406803/toggling-a-gpio-on-cla 

    From what you are attempting to do it should be possible to toggle a GPIO using the existing driverlib. Can you confirm if you include a function call to the 

    GPIO_setControllerCore(uint32_t pin, GPIO_CoreSelect core);
    ?

    This function configures which core owns the specified pin's data registers (DATA, SET, CLEAR, and TOGGLE). The core parameter is an enumerated data type that specifies the core, such as GPIO_CORE_CPU1_CLA1 to make CPU1's CLA1 controller of the pin.

    Here's a forum post with an almost similar question that you can reference: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/406803/toggling-a-gpio-on-cla 

    Let me know your findings.

    Regards,

    Ozino

  • Hi Ozino,

    Thank you for your reply.

    GPIO access is not my issue. it was just an example and I used it as it uncovered a much more serious issue.

    My issue is that, most likely incorrect code is generated by C2000, or a silicon bug is exposed.

    I re-phrase the problem:

    The following function call from within Cla1Task1 causes all interrupts to be disabled or seriously malfunction, on CLA1 and perhaps also CPU1, plus probably some other corruption as well.

    static inline void cla_test(uint32_t x)
    {
      volatile uint32_t y;
      y=1<<x;
    }

    :

    __interrupt void Cla1Task1 ( void )
    {
    :
       cla_test(9);
    :

    Using the debugger I can see the main loop of code in CPU1 is running, interrupts not running correctly - looks like they're partially disabled or produce incorrect behavior, CLA1 interrupt code does not run at all, junk on PWM signals, etc.
    Thank You,
    -Alon.

  • Hi Alon,

    Thanks for the clarification. I'll try to recreate this test case and get back to you if i'm able to replicate your setup.

    Regards,

    Ozino

  • So i attempted to recreate your test setup and I'm not able to observe your issue. Here's my test scenario:

    Import CLA_ex4_pwm_control example from C2000Ware. 

    Modify the .cla file to add the code snippets, with some additional code to change the y value whenever the left shift completes, to the existing ClaTask1 routine. Compiled and flashed to the target.

    • I added a line calling the __mdebugstop(). This allows us to halt CPU and debug the CLA during run time.

    Connected and loaded the symbols to the CLA core.

    Ran the CPU and waited for it halt in the .cla file. I then ran and observed the state of the y variable and saw expected behavior.

    However, when running the same code without the line of code to stop halt the CPU (mdebugstop) I noticed incorrect values but the rest of the system performance execute as normal.

    Can you attempt to debug the CLA with the code you described within an example in C2000Ware and compare if it works?

    Regards,
    Ozino