PWM drifting with increasing dutycycle

hartltech
Posts: 3
Joined: Mon Oct 19, 2020 8:39 am

PWM drifting with increasing dutycycle

Postby hartltech » Mon Oct 19, 2020 10:35 am

Hello everyone,

I just started programming an ESP32 and already ran into some problems. I use the Arduino framework of the 'Visual studio code' and the MCPWM library. I adapted the code from https://hackaday.io/project/169905/logs?sort=oldest

Code: Select all

#include <Arduino.h>
#include "driver/mcpwm.h"  
#include "soc/mcpwm_reg.h"
#include "soc/mcpwm_struct.h"

#define GPIO_PWM0A_OUT 12   //Declara GPIO 12 como PWM0A
#define GPIO_PWM0B_OUT 14   //Declara GPIO 14 como PWM0B

void setup() {
  Serial.begin(9600);
  mcpwm_gpio_init(MCPWM_UNIT_0, MCPWM0A, GPIO_PWM0A_OUT);
  mcpwm_gpio_init(MCPWM_UNIT_0, MCPWM0B, GPIO_PWM0B_OUT); 

  mcpwm_config_t pwm_config;
 
  pwm_config.frequency = 3200;                          //frequência = 500Hz,
  pwm_config.cmpr_a = 90;                                //Ciclo de trabalho (duty cycle) do PWMxA = 0
  pwm_config.cmpr_b = 90;                                //Ciclo de trabalho (duty cycle) do PWMxb = 0
  pwm_config.counter_mode = MCPWM_UP_COUNTER;           //Para MCPWM assimetrico
  pwm_config.duty_mode = MCPWM_DUTY_MODE_0;             //Define ciclo de trabalho em nível alto
  //Inicia(Unidade 0, Timer 0, Config PWM)
  mcpwm_init(MCPWM_UNIT_0, MCPWM_TIMER_0, &pwm_config); //Define PWM0A & PWM0B com as configurações acim
  
  //mcpwm_sync_enable(MCPWM_UNIT_0, MCPWM_TIMER_0, MCPWM_SELECT_SYNC_OUT0, 0);

  //MCPWM0.timer[0].sync.out_sel = 1;
  //delay(100);
  //MCPWM0.timer[0].sync.out_sel = 0;

  //mcpwm_set_duty(MCPWM_UNIT_0, MCPWM_TIMER_0, MCPWM_OPR_A, 70);
  //mcpwm_set_duty(MCPWM_UNIT_0, MCPWM_TIMER_0, MCPWM_OPR_B, 60);

  Serial.println("Setup");

  delay(50);
}

void loop() {
  
  Serial.println("Loop");
for(int i=0;i<100;i++) {
  mcpwm_set_signal_low(MCPWM_UNIT_0, MCPWM_TIMER_0, MCPWM_OPR_B);
  mcpwm_set_duty(MCPWM_UNIT_0, MCPWM_TIMER_0, MCPWM_OPR_A, i);
  mcpwm_set_duty_type(MCPWM_UNIT_0, MCPWM_TIMER_0, MCPWM_OPR_A, MCPWM_DUTY_MODE_0);
  Serial.println(i);
  delay(250);
  }

  delay(1000);
}
I have two issues:
  • The output signal is not a true rectangle, but clearly distorted on the edges
  • The signal drifts with increasing duty cycle
The signal starts around 0 to 5V and 'drifts' to 0 to -5V with increasing duty cycle. Attached are the signals for 10% and 90%. Vpp is 5V

My setup: ESP32-Devkit pcb connected to a notebook. The signal is measured using an oscilloscope against GND.
Attachments
esp32-90.jpg
esp32-90.jpg (45.24 KiB) Viewed 3653 times
esp32-10.jpg
esp32-10.jpg (45.9 KiB) Viewed 3653 times

ESP_Sprite
Posts: 9730
Joined: Thu Nov 26, 2015 4:08 am

Re: PWM drifting with increasing dutycycle

Postby ESP_Sprite » Tue Oct 20, 2020 2:19 am

Are you sure your oscilloscope is in DC mode, not in AC mode?

hartltech
Posts: 3
Joined: Mon Oct 19, 2020 8:39 am

Re: PWM drifting with increasing dutycycle

Postby hartltech » Tue Oct 20, 2020 6:05 am

I found the error. I started the lab equipment today and found out that my notebook did not have power. The cable of the power supply was not plugged in correctly and therefore the power source (via USB) was floating connected to an grounded osci.

The PWM signal behaves as expected and on the flanks are no oscillations anymore.

Thats one drawback of high battery life.

ESP_Sprite
Posts: 9730
Joined: Thu Nov 26, 2015 4:08 am

Re: PWM drifting with increasing dutycycle

Postby ESP_Sprite » Tue Oct 20, 2020 6:36 am

Ooh, tip for the future: you probably want to use the ground clip/connection/wire on your scopes probe for grounding. Not only would you sidestep the issue you have here, a ground that goes over the power supply of your devices also introduces a huuuge ground loop that makes your measurements very vulnerable to any and all noise that floats around in the air.

hartltech
Posts: 3
Joined: Mon Oct 19, 2020 8:39 am

Re: PWM drifting with increasing dutycycle

Postby hartltech » Tue Oct 20, 2020 1:12 pm

Usually the lab equipment runs on its own ground. For development and debugging purposes we use our own notebooks for quick access.

In this case it was a combination of convenience and faulty handling

Who is online

Users browsing this forum: No registered users and 44 guests