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.

CC1352P: cc1352 pwm behavior

Part Number: CC1352P
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi all,

I need the cc1352 issues an interrupt on a pwm edge, but this seems to be not functional. Here following a simple snippet of the code:

void Pulse_CallBack ( GPTimerCC26XX_Handle hTimer, int_fast16_t nStatus )
{
  // toggle an indicator LED
  GPIO_toggle ( CONFIG_GPIO_27_LED_2 );
} // end of "Pulse_CallBack ()"

PWM_init();
PWM_Params_init ( &pwmParams );
pwmParams.periodValue = 400;
// 50% duty cycle
pwmParams.dutyValue = ( uint32_t )((( uint64_t ) PWM_DUTY_FRACTION_MAX * 50 ) / 100 );
PWM_Handle hPwm = PWM_open ( CONFIG_EXC_CLK, &pwmParams );
if ( hPwm == NULL )
{
  // PWM_open() failed, stall here
  while ( true );
} // endif
PWMTimerCC26XX_Object* pObject = hPwm -> object;
GPTimerCC26XX_Handle hTimer = pObject -> hTimer;
// generate interrupt on match
GPTimerCC26XX_registerInterrupt ( hTimer, ( GPTimerCC26XX_HwiFxn ) Pulse_CallBack, GPT_INT_MATCH );
PWM_start ( hPwm );

// stall here for test only
while ( 1 );

The Pulse_CallBack is never reached while the pwm signal is correctly visible on the selected output (determined with sysconfig). This never happens independently of the the value of the GPTimerCC26XX_Interrupt mask (that is using either GPT_INT_TIMEOUT, GPT_INT_CAPTURE_MATCH, GPT_INT_CAPTURE or GPT_INT_MATCH)
Where is my error?

Thanks,

sincerely Luigi

  • Hi Luigi,

    how did you use SysConfig to verify the pwm signal?

    In general, did you already checkout our pwmled2 example of the SDK? 

    If I understand you correctly then you want to generate a pwn signal on one of the GPIOs and then execute a callback every time that this pwm signal is changing?
    Since you know the duty cycle, why are you not using this to trigger the callback?

    Kind regards,
    Theo

  • Hi Theo,

    I' m very sorry to waste you time: I really found the origin of this issue: there was a mistake in getting the correct SDK (I mutuated a very old project from my customer so I was misled taking the old project that it is said "it' s working" - and really it is not) so the source was coded with wrong references. Opening a clean new project, the issue disappears and a correct interrupt is generated on every rising PWM edge, exactly what I need
    Resolved issue, thanks