• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 167 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F280049: TIDM-02002 : CLLC HAL Bugs?

Kier
Mastermind 8015 points
Part Number: TMS320F280049
Other Parts Discussed in Thread: C2000WARE

Hello,

I think there's two bugs in  the following file:

C:\ti\c2000\C2000Ware_DigitalPower_SDK_4_01_00_00\solutions\tidm_02002\f28004x\drivers\source\clllc_hal.c

Bug 1)  Lines 1687,1688:

Fullscreen
1
2
HWREGH(CLLLC_SEC_LEG2_PWM_BASE + EPWM_O_DBCTL) =
(HWREGH(CLLLC_SEC_LEG1_PWM_BASE + EPWM_O_DBCTL) | 0x3000);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

              
The EPWM base is different between the two lines, i.e. LEG2 vs LEG1. Shouldn't they be the same?

Bug 2) Line 1879:

Fullscreen
1
ECAP_clearInterrupt(base1, 0xFF);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

 The line does not pass the ASSERT check when DEBUG is defined because an attempt is made to clear the global interrupt flag, Bit 0, which is not in the scope of the function. I think it should be 0xFE at the very least:

Fullscreen
1
ECAP_clearInterrupt(base1, 0xFE);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

For optimal readability it should be:

Fullscreen
1
2
3
4
5
6
7
ECAP_clearInterrupt(base1, ECAP_ISR_SOURCE_CAPTURE_EVENT_1 |
ECAP_ISR_SOURCE_CAPTURE_EVENT_2 |
ECAP_ISR_SOURCE_CAPTURE_EVENT_3 |
ECAP_ISR_SOURCE_CAPTURE_EVENT_4 |
ECAP_ISR_SOURCE_COUNTER_OVERFLOW |
ECAP_ISR_SOURCE_COUNTER_PERIOD |
ECAP_ISR_SOURCE_COUNTER_COMPARE);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Thank you.

  • +1
    TI__Mastermind 42195 points

    Kier,

    I agree on bug 1. This does look to be a bug. This is lucky because it does not have an effect on the code execution because both secondary legs have the same deadband configuration.

    For bug 2 I also agree. It looks like this statement is intended to clear all interrupt sources, which explains why 0xFF was chosen. As you have indicated if FF does not pass the assert then I believe this is probably an accidental bit which is reserved or otherwise unrelated. 

    I'll submit bugs fix requests to have these updated.

    Regards,
    Cody 

  • 0 in reply to Cody Watkins
    Mastermind 8015 points

    Thank you for the clarification.