Trouble with PWMs

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I'm using a fast loop to just read the outputs of the SARADC into some TCPWMs. It mostly works, but there are glitches. The glitches are all "full on" periods. The glitches are not in any way synchronized with incoming data: they are still there with dc in. The ADC is set to 10 bits (single ended, no averaging), and in fact I masked out any potential high bits that might be set (I'm also shifting the data right) just in case that was the problem (the docs for the ADC use dashes not zeroes for the Right/Unsigned format, and just in case they don't really mean that null is 0, I tried this). I also put in a test: if the ADC was not ready I forced the reading to zero. Neither step helped, so I'm suspecting that the fast, repetative, writes to the PWMs are the problem and that sometimes the Compare register is being written while it is also being used?

   

I'm having trouble understanding the meaning of section 17.3.4.2 of the 4100/4200 TRM: does this mean that just writing to the Buffer Compare register needs to be synchronized with TC in software? (For my application the period register is fixed at 1023, so I'd not have to update that.)

   


The only ISR I'm using is one from the SCB in SPIS mode: that is working fine. I'm using it to receive global variables which control the shifting (right) of the data received from the ADC into the PWMs. Again, that works.

   


I interpreted the double headed arrow in 17.3.4.1 (etc.) to imply a "ping-pong" type of configuration where the software writes to the "Buffer compare" register while the "Compare" register is "live". Is this wrong? And what is a "switch event"? If that originates with the switch input then I don't have any..but the PWM is being updated, and most of the time with the right data, so what is the actual architecture?

   

I'm using a CY8CKIT-049-42.

   

{First posting, man this Forum software is bad..I know you all know this from other comments !}

0 Likes
5 Replies
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

From the Architecture TRM -

   

 

   

   

 

   

So these registers are double buffered.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

As stated, I saw those words.  I interpreted them much as you did. The term "switch event" seemed to be not defined, however I just saw it: in 17.2.3 the terms reload event, start event, count event, stop event and capture event are all defined, but for the last (subtly) "in PWM modes, the capture event acts as a switch event. It switches the values of the capture/compare and period registers with their buffer counterparts."  OK so now the first sentence makes a bit more sense. It is unclear to me whether the next one means that the AUTO_RELOAD_CC and AUTO_RELOAD_PERIOD fields of the control register are set by the hardware because of the event, or that these must be set by the software for this action to happen. The next sentence is clear, changes won't take effect 'till a TC, that is as one would hope (and it seems to be repeated in the next bullet). WTF the last sentence though..."pass through signal (selected during detection setting) cannot trigger a switch event"???

   

And I fail to see the correspondence between all this and the PWM set-up via the configure at the "schematic" level: in that there are check boxes which seem to enable the swap for either or both the Period and Compare registers. I have not enabled this, maybe I should be? And likewise there is a check box to include an input called "switch" which is also not checked: I assumed that was only for a hardware command to toggle betwen two values, swapping either or both registers if the swap checkboxes were checked.

   

All my symptoms are consistent with the Compare register sometimes holding values bigger than the Period register, and I thought that could be happening because I am writing to (the buffer version of) it very frequently and catching it during a state transition.

   

Does this make sense to anybody?

   

{I've been getting micros to talk to programmable timers for almost 40 years, I'm no noob here! I remember my first...}

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

One of the limitations here is the Func Descrip section of datasheet

   

not as complete as in most other components. We cannot tell what is

   

synch to a  clock and not.

   

 

   

All my symptoms are consistent with the Compare register sometimes holding values bigger than the Period register, and I thought that could be happening because I am writing to (the buffer version of) it very frequently and catching it during a state transition.

   

 

   

Going out on a limb if its like the PSOC 1 solution ist a simple gate level comparator so should not

   

have any gotchas in its operation.

   

 

   

You might file a CASE on this or at least post a test project for forum to look at.

   

 

   

Regards, Dana.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Well, I got back to this this morning. It certainly seems like the compare register is NOT buffered at least in the configuration I used. So either I missed something in the setup or the classic PWM problem of writing a new, smaller than previous compare value into the register between the time when the new one will compare but before the time (count) when the previous one would have compared, has reared its ugly head.

   

The stripped down test case should demonstrate this as long as a scope or logic anaylzer is available.

   

 

   

[edit] It should be obvious that I was blowing smoke above...I am not writing to the buffer version of the compare register. When I did that the PWMs did nothing. Maybe a clue?

   

[edit 2] It seems clear from the component's data sheet that period and/or compare register swaps can only happen as a result of a hardware input, see the descriptions for TCPWM_SetPeriodSwap() and TCPWM_SetCompareSwap(). I've tried modifying the test case to use an isr, and the problem still happens but in a smaller set of circumstances I think.

   

[edit 3] OK, the solution, I know you have all been waiting for: an interrupt on CC_MATCH (NOT on TC) did the trick. I guess I can post another zip here? Well, maybe not got several screens-full of Coldfusion error log! I'll have to start a new entry...

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Maybe posting the 2nd archive will work now...

0 Likes