4 Replies Latest reply on Dec 11, 2014 4:46 AM by arun.asokan

    PWM signal behaviour is not predictable

    frank.bartl

      I configured one GPIO pin as PWM signal by using API call CyU3PGpioSetComplexCon´Čüg. Measured signal waveform was different to program code. It seems threshold value was not set, so PWM signal was half the frequency with a duty-cycle of 50%.

         

      To check behaviour I used following program code:

      volatile uint32_t                   period    = 100800;
      volatile uint32_t                   threshold = 1000;

      while (1)
      {
         ...

         CyU3PThreadSleep (250);

         ...

         DBG_INFO_VALUE("thershold = ", threshold);
         status = CyU3PGpioComplexUpdate (FX3_FPGA_TRIG_FX3, threshold, period - 1);
         threshold += 1000;
         if (threshold > period)
            threshold = 1000;
      }


      I expect to see a PWM signal with increasing duty-cycle. Duty-cycle never become equal or greater than 100% and when close to 100% duty-cycle “jumps” back to nearly 0%. PWM frequency is 1kHz.

         

      --> Measured signal is different: Duty-cycle is increasing and then decreasing.

         

      For lower PWM frequency (1Hz to 10Hz?) it seems there is a problem with very small or very large duty cycles. These values are not “excepted”, signal stays low or high.

         

      And as last point, it seems not possible to define start value for a PWM signal. This means it seems signal is inverted!

         

      Did someone run into the same problem?

      Frank

        • 1. Re: PWM signal behaviour is not predictable
          shashank.rebbapragada

           Hi,

             

           

             

          We have noticed an issue with the threshold level not being reflected correctly for high PWM frequencies.

             

          I think a similar issue is also seen here with low frequencies. We will check on this as well.

             

          We do not have an update as of now for working around this issue. We will update the forums when we have this available.

             

           

             

          Btw, you can set the initial value of your PWM signal using the outvalue parameter of the CyU3PGpioComplexConfig_t structure.

             

           

             

          -Shashank

          • 2. Re: PWM signal behaviour is not predictable
            arun.asokan

             If I use period 2 and threshold 1 , then i get 32MHz and if I use period 3 and threshold 2, then I get 42MHz ! the 50% duty cycle doesnt even show up on the wave on higher frequencies. Why this wierd behaviour and is there any actual conversion available ?

            • 3. Re: PWM signal behaviour is not predictable
              shashank.rebbapragada

               Hi,

                 

               

                 

              The issue seems to be because of a fault in the GPIO block logic of Fx3.

                 

               

                 

              We have investigated and found these results:

                 

              Clk_src = SYS_CLK = 384 MHz
              Fast_clk = SYS_CLK/2
              Pin_mode = PWM
              Timer_mode = High_freq (fast_clk)

                 

               

                 

              1. If you set PERIOD to 3 and THRESHOLD to 1, you get a PWM waveform with 50%
              duty cycle; and a frequency of (SYS_CLK / (2 * 8)) (~24 MHz).
              2. If you set PERIOD to 3 and THRESHOLD to 2, you get a PWM waveform with 50%
              duty cycle; and a frequency of (SYS_CLK / (2 * 4)) (~48 MHz).

                 

               

                 

              Setting the THRESHOLD to 1 is causing some issues for the PWM generation as a whole. However, the THRESHOLD should be set to 2 in this case to get a 50% duty cycle.

                 

               

                 

              Regards

                 

              Shashank

              • 4. Re: PWM signal behaviour is not predictable
                arun.asokan

                 Thanks for resolving.