KL03 TPM: CMOD gets changed to zero each time TPM_DRV_PwmStart() runs

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

KL03 TPM: CMOD gets changed to zero each time TPM_DRV_PwmStart() runs

Jump to solution
655 Views
aes_mike
Contributor III

It seems that each time the TPM_DRV_PwmStart() is run that the TPM0.SC.CMOD gets set to zero.  As a result the PWM output never changes at pin PTA6.  Attached is a screen shot.   If I set a breakpoint just after the TPM_DRV_PwmStart() and then change CMOD back to 0x1, then it works fine.    It is not clear to me why CMOD reverts to zero after TPM_DRV_PwmStart()?  Any suggestions?    I just want to be able to adjust the PWM output at any time.  I am not real familiar with the TPM, so some of this might be just misunderstanding how it works.

 

I have setup the TPM0 as a PWM output.

 

tpm_general_config_t  main_tpm_config;

tpm_pwm_param_t main_tpm_timer_channel_config = {
  .mode = kTpmEdgeAlignedPWM,
  .edgeMode = kTpmHighTrue,
  .uFrequencyHZ = 100000U,
  .uDutyCyclePercent = 50U,
};

 

Initialization portion:

  CLOCK_SYS_SetTpmSrc( TPM0_IDX, kClockTpmSrcIrc48M );
  TPM_DRV_Init( TPM0_IDX, &main_tpm_config );
  TPM_DRV_SetClock( TPM0_IDX, kTpmClockSourceModuleClk, kTpmDividedBy2 );
  main_tpm_timer_channel_config.uDutyCyclePercent = 50;
  TPM_DRV_PwmStart( TPM0_IDX, &main_tpm_timer_channel_config, 0U );

 

 

Software:  KDS 3.0.0, KSDK 1.3.0.

Labels (1)
0 Kudos
1 Solution
436 Views
aes_mike
Contributor III

To close out this question and help others out there struggling with similar issue, it turns out that the issue is a stack overflow problem which is clobbering the global variable (s_tpmClockSource) that you mentioned.  I setup a watchpoint on that variable and sure enough it was being change in unexpected ways.   That is why the PWM appears to come and go because the s_tpmClockSource is used to write to CMOD anytime TPM_DRV_PwmStart() is run.

I now have set a watchpoint at the bottom of the stack and that has helped as well as using the -fstack_usage flag for the GCC compiler which produces a report on the stack foot print of each function that is compiled.  

View solution in original post

0 Kudos
3 Replies
436 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi,

As you know that condition  the TPM counts tick is that the CMOD bits can not be 0 or 3. So before you call the TPM_DRV_PwmStart(), you have to call  TPM_DRV_SetClock(BOARD_BUBBLE_TPM_INSTANCE, kTpmClockSourceModuleClk, kTpmDividedBy2);

The TPM_DRV_SetClock() can assign the kTpmClockSourceModuleClk to a global variable so that the global variable can set up the CMOD bits in TPM_DRV_PwmStart().

//BOARD_BUBBLE_TPM_INSTANCE=0;

Hope it can help you

BR

XiangJun Rong

0 Kudos
437 Views
aes_mike
Contributor III

To close out this question and help others out there struggling with similar issue, it turns out that the issue is a stack overflow problem which is clobbering the global variable (s_tpmClockSource) that you mentioned.  I setup a watchpoint on that variable and sure enough it was being change in unexpected ways.   That is why the PWM appears to come and go because the s_tpmClockSource is used to write to CMOD anytime TPM_DRV_PwmStart() is run.

I now have set a watchpoint at the bottom of the stack and that has helped as well as using the -fstack_usage flag for the GCC compiler which produces a report on the stack foot print of each function that is compiled.  

0 Kudos
436 Views
aes_mike
Contributor III

Also, as I sweep the PWM from 0 to 100, incrementing the PWM by one each second, I notice that the output frequency will vary from 100KHz, 366Hz or DC.  In other words, it does not seem to be operating in a PWM mode from perspective of the output at PTA6.  Mike.

0 Kudos