TCPWM->PWM with switch -> wrong output?

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

cross mob
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi,

   

 

   

I configured a TCPWM block as PWM with the following settings:

   
        
  • input clock 1Hz
  •     
  • left aligned
  •     
  • normal PWM mode
  •     
  • switch input active
  •     
  • Period 4, period buffer not used/switched
  •     
  • Compare 1, compare buffer 3
  •     
  • Compare output connected to switch input
  •    
   

From the above I'd expect a frequency of 0.2Hz (5s), and a pulse width of 1s and 4s. However, I can only see the 1s pulse with a period duration of 5s, so it seems the switch isn't recognized. Cypress confirmed that the OV/UV/CC signals are based on HFCLK, so their pulse widths are one HFCLK cycle in length. Since the TCPWM samples the trigger input with HFCLK the pulse couldn't be recognized by the TCPWM itself.

   

I added a SRFF with HFCLK as clock, TCPWM compare output as 'set' and TCPWM overflow as 'reset'. Now the TCPWM switches the compare values as expected, but the expected 4s pulse is only 3s. Can anyone reproduce it?

   

 

   

Regards,

   

 

   

Ralf

0 Likes
6 Replies
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

I'm not exactly sure when the switch inout gets samples - the DS says 'at the next timer / counter' event. But it might be that it happens at a time when the output is already 0 again, so you won't get the second buffer.

   

But when I read the DS right, you can just activate the 'swap' checkbox in the compare register definition, and then the PWM should swap the two values at the end of each PWM period.

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi Hli,

   

 

   

according to the TRM the event signal is buffered until the TC event, so it shouldn't matter if the original switch signal is already low again.

   

I don't want to swap the compare values on each TC event, the above configuration is only for testing. The end design should be able to generate two different 'bit-coded' pulse lengths. In fact I need three states:

   
        
  1. IDLE state with output low
  2.     
  3. generate pulse width A on a cleared bit
  4.     
  5. generate pulse width B on a set bit
  6.    
   

I'm trying to solve the pulse width part by TCPWM to keep needed hardware ressources low - the decoding of the bits into the TCPWM would consume enough hardware, I think 😉

Regards,

   


Ralf

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

When I look at the example of the TCPWM component, page 36, it looks like the switch signal is level-triggered and sampled at terminal count (TC). Since you use the compare output as switch signal, this will be always 0 at this point.

   

So your solution with the SR-FF is the right one, but for the wrong reason 🙂

   

Regarding the period: I think the TCPWM always does 'less than' compare, so the compare value matches the pulse length (whereas the period length is period value +1). (Actually its a direct compare, but the line gets toggled on that event, so a compare value of one gets triggered after one pulse).

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi Hli,

   

 

   

When I look at the example of the TCPWM component, page 36, it looks like the switch signal is level-triggered and sampled at terminal count (TC). Since you use the compare output as switch signal, this will be always 0 at this point.

   

This shouldn't be a problem, according to PSoC4 TRM the TCPWM block recognizes the switch event until the TC event, even if the switch signal itself is inactive at this point.

   

 

   

So your solution with the SR-FF is the right one, but for the wrong reason 🙂

   

I wonder why the TCPWM block isn't capable of recognizing those signals directly.

   

 

   

Regarding the period: I think the TCPWM always does 'less than' compare, so the compare value matches the pulse length (whereas the period length is period value +1). (Actually its a direct compare, but the line gets toggled on that event, so a compare value of one gets triggered after one pulse).

   

I think the problem is not the buffered compare value as I thought at first, but the customizer: according to register TRM the period value should always be N-1 (that's why I used the value of 4 for 5 seconds). However, the compare value should also be N-1, but seems to be N in the customizer.

   

 

   

Regards,

   

 

   

Ralf

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

The problem is that there are two sources for the switch signal: either by software, or by the hardware input. For the software its clear that its buffered. But for the input signal I'm not so sure. The TRM shows (in figure 17-2) that there is a pass-through mode, which is in essence a level-based detection. That one would not be buffered (its the edge dectector doing the buffering - when it sees an edge, its output goes high, and stays there until it's reset). And I think thats how the switch input works. But you can always file a case with Cypress and ask for clarification...

   

Also, the TRM says (in the same place): "When more than one event occurs in the same counter clock period, one or more events may be missed." Maybe thats whats happening?

   

Regardign the pulse length: IMHO it's correct to be that way. A period of 0 disables the PWM, witout stopping it. Otherwise, the minimum pulse length is 1 (and you can only have it always one by setting pulse==period, so the capture condition is never reached). The TRM also explains it that way.

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi Hli,

   

 

   

when enabling the hardware inputs, the customizer automatically select rising edge.

   

 

   

Regarding missing events, none of the inputs are active at the same time.

   

 

   

Regards,

   

 

   

Ralf

0 Likes