KL02Z PWM Issue about CnV = 1

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

KL02Z PWM Issue about CnV = 1

1,094 Views
ellenlin
Contributor III

Dear NXP , 

   I Follow this : PWM Duty Cycle Issue - Kinetis L ( MKL26Z128 ) 

   And we use FRDM-KL02Z , found that when we modify C0V = 1 will happen a Full Duty waveform 

   asd.jpg

   So we supply thePWM Duty Cycle Issue - Kinetis L ( MKL26Z128 ) to customer and let them avoid " 1 " value into C0V

   Have any document about this ? ( Errata sheet ) Customer need this .

   and whether this will make other module fail ? ( ADC ? UART ? any others ) 

   this issue happen in KL02Z , How about other KL series ic ? Has already fix this ? Thanks a lot !! 

Labels (1)
Tags (3)
0 Kudos
9 Replies

815 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello,

Could you please provide more information, for example: at what frequency are you working? where in your program are you changing the duty cycle, in the interrupt or in another place? 

I tried the example tpm_simple_pwm of the SDK along with the FRDM-KL02Z board. I modified the code to see the signal in a oscilloscope and I wrote "1" directly to the CnV register and everything worked fine. 

I checked the errata and there is no information available regarding the behavior that you mentioned. Could you please try with the example of the SDK?   

Regards, 

Victor.

0 Kudos

815 Views
ellenlin
Contributor III

Dear  Victor Jimenez :

   Provide Code Warrior project to you ,

   We use TPM1 Interrupt to modify TPM0 Duty Cycle , AND This happen , 

   you can try attachment file in Code warrior IDE , THANKS!!  

0 Kudos

815 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello,

I modified the example tpm_simple_pwm from the SDK 2.3.1 to follow the steps that you mentioned. I use TPM0 interrupt to write constantly 1 in the CnV register of the TPM1 and everything worked fine, I wasn't able to reproduce the behavior that you mention.

I don't have Code Warrior IDE installed, since we are push to use our newest tools, like MCUXpresso IDE and SDK. I noticed in your example code that you are using Processor Expert, this made me think that the behavior that you are facing is due to this. Is it possible for your customer to make the migration to MCUXpresso and SDK? Please let me know if this is not an option.

    

Regards,

Victor. 

0 Kudos

815 Views
ellenlin
Contributor III

Dear Victor Jimenez 員工

   My Customer has already use CW for several years , 

   it ' s not a good choice to change IDE , Their FW Team is too large and they don't prefer this , they want a document to explain this issue . 

   I use TPM1 ( Period = 100uS ) Interrupt to modify TPM0 ( Period = 20 us ) Duty cycle .

   

   Really need NXP 's Support to check this , thanks a lot !!

0 Kudos

815 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello,

Thanks for providing more information. I ran the project that you provided and I was able to reproduce the behavior that you mentioned. However, I noticed that once I stopped the debug session the program starts to function as expected, see photo below. 

pastedImage_1.jpg

It seems that the behavior is due to the debug session. In runtime, you can write one to the CnV register without any problem.  

Regards,

Victor. 

0 Kudos

815 Views
ellenlin
Contributor III

Dear Victor Jimenez 員工 ,

   I has already try the method you mentioned , but nothing was happen , stiil the same issue , 

   

   And my customer , too . Have any document about this to explain this issue ? i has already provide PWM Duty Cycle Issue - Kinetis L ( MKL26Z128 )  answer to them and i think this can be avoid by " if " function . and customer has already accept this . 

   But they want a Errata answer this , thanks a lot !!!

0 Kudos

815 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello,

 

When I ran your project from the debug session even if I use free run I could reproduce the behavior you mentioned. However, once I stopped/exited the debug session completely and restart the board the behavior was gone and the program was running as expected. I couldn’t reproduce the behavior while running your project without an open debug session. The behavior you are facing is due to the debug session of code warrior, not the MCU, so there are not available errata for this since the problem is not from the MCU. I’m still investigating how the debug session is messing with the time of the peripheral TPM.    

 

Hope it helps!

Victor.

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

0 Kudos

815 Views
ellenlin
Contributor III

Dear Victor Jimenez 員工

   Thanks for your help , i think why this will happen is more important ~

   i 'm still can't solve the issue like you did , i has already consult the Technical Support for customer , thanks for your help !!

0 Kudos

815 Views
ellenlin
Contributor III

Dear Victor Jimenez 員工 ,

   You means stop debug method , use free run then won't happen this issue ? i ' ll try this ~

   and why debug method will happen this ?  Customer will ask this question , i think it's very important . 

   Thanks a lot !! 

0 Kudos