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.

TM4C129XNCZAD: ASSERT in PWMClockSet

Part Number: TM4C129XNCZAD


Device:     TM4C129XNCZAD
Driverlib:    2.1.4.178

Predefined Compiler Symbols:
    PART_TM4C129XNCZAD
    TARGET_IS_TM4C129_RA2
    DEBUG


When initialising the PWM using...
    
    PWMClockSet( PWM0_BASE, PWM_SYSCLK_DIV_1 );
    
The ASSERT at the entry of this function does not include PWM_SYSCLK_DIV_1 in the validation checks for the second parameter, and consequently the ASSERT triggers.
Is this an oversight? Or is PWM_SYSCLK_DIV_1 actually an illegal parameter?

Regards.

  • Hello Tony,

    PWM_SYSCLK_DIV_1 is a valid parameter, but it looks like it was missed in the API. I've gone ahead and inputted this issue into our bug tracking system so it may be resolved with the next update.

    Since the release version of driverlib does not include the overhead of the ASSERT macros, we haven't heard about this issue before, so thank you for bringing this up so we can get it addressed.
  • Thanks for the information Ralph.

    On a related issue, there is a similar problem in driverlib's TimerConfigure() parameter validation . As an example...

    TimerConfigure( TIMER1_BASE, TIMER_CFG_SPLIT_PAIR | TIMER_CFG_A_PWM | TIMER_CFG_B_ACT_NONE );

    The intent is to use TIMER1 in split mode, using TIMER_A for PWM control, and leaving TIMER_B idle. This triggers the

    parameter validation ASSERT for the TIMER_CFG_B_* field of the configuration parameter.

    Regards.

    Tony.

  • Hi Tony,

    Sorry for the delay in reply, it looks like one Assert checks for TIMER_CFG_SPLIT_PAIR correctly, but I've been trying to figure out the other one, which I think you are being tied up by, and it looks to be wrong to me. The intent seems to be to ASSERT if the SPLIT_PAIR is not used and both A and B are being configured together, but from what I can follow that wouldn't happen because of how the checks are strung together.

    Also there was another issue with this assert set which you may run into if you end up not using the SPLIT PAIR functionality: https://e2e.ti.com/support/microcontrollers/other/f/908/p/710129/2617541#2617541

    It doesn't look like the asserts for the TM4C129x MCU's were added either, but that's a different topic and I suspect that was done because it would be difficult to mask out the checks for the correct MCU's...

    In any case, we will have to do a serious review of the ASSERTs for that function as it looks like the prior engineers who wrote it did a poor job...