You are here

UDB based PWM Mis-Behaviour / Bug | Cypress Semiconductor

UDB based PWM Mis-Behaviour / Bug

Summary: 0 Replies, Latest post by Bob Marlowe on 15 Apr 2014 08:08 AM PDT
Verified Answers: 0
Log in to post new comments.
user_1377889's picture
9249 posts

I agree that a one-shot (with multi-trigger) PWM is not the everyday usage of a PWM, but I had a design where this was the only right solution.

When the PWM reaches terminal count (TC) I change programmatically the period by using the appropiate API, assuming that the PWM would be in the very same state as if It had stopped it with the API PWM_Stop() and now needs a hardware trigger to run once more.


To my surprise I discovered that when the PWM was triggered again the newly programmed period has not been accepted and the previously written period value was taken instead, so it looked like a one-cycle delay of the PWM's period. Experimental delays did not change the situation.


Of course I did create a MyCase and it took 14 days(!!) for Cypress's conclusion that the behaving of the PWM is quite o.k. since the datasheet tells that in a running PWM the next period is red at TC, while I still believe that the PWM is stopped and should accept the new value immediately.


When talking about fixed-function components I would accept that because changing would require a change in the silicon but since we are in PSoC world with UDB components a simple "repair" of the component would remove this obvious error, at least a clarification in the datasheet would save us some hours of trial-and-error testing.




Log in to post new comments.