ledc example does not work at all

[ESP_igrr]

So you get incorrect period with the code posted above, and ledc_update_duty added to it?

Here's the code I have tried (made delays shorter to see the result better on the scope):

Code: Select all

#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/xtensa_api.h"
#include "driver/ledc.h"
#include "esp_attr.h"
#include "esp_err.h"

#define LEDC_IO_0    (19)

esp_err_t app_main()
{

    ledc_timer_config_t ledc_timer = {
        .bit_num = LEDC_TIMER_13_BIT,
        .freq_hz = 5000,
        .speed_mode = LEDC_HIGH_SPEED_MODE,
        .timer_num = LEDC_TIMER_0
    };
    ledc_timer_config(&ledc_timer);

    ledc_channel_config_t ledc_channel = {
        .channel = LEDC_CHANNEL_0,
        .duty = 100,
        .gpio_num = LEDC_IO_0,
        .intr_type = LEDC_INTR_DISABLE,
        .speed_mode = LEDC_HIGH_SPEED_MODE,
        .timer_sel = LEDC_TIMER_0
    };
    ledc_channel_config(&ledc_channel);

    while(1) {
        ledc_set_duty(LEDC_HIGH_SPEED_MODE, LEDC_CHANNEL_0, 8000);
        ledc_update_duty(LEDC_HIGH_SPEED_MODE, LEDC_CHANNEL_0);
        vTaskDelay(2);

        ledc_set_duty(LEDC_HIGH_SPEED_MODE, LEDC_CHANNEL_0, 2047);
        ledc_update_duty(LEDC_HIGH_SPEED_MODE, LEDC_CHANNEL_0);
        vTaskDelay(2);
    }
}

Screen Shot 2017-03-01 at 13.43.57.png (38.46 KiB) Viewed 13439 times

[murray_lang]

It's not incorrect period. There is no PWM period. Each of those changes in that previous image are 2 seconds in duration. The CRO was on a very slow sweep. The LOW sections are 2 seconds long corresponding to 0 duty cycle. The HIGH sections are 2 seconds long corresponding to non-0 duty cycle.

I ran your code and have captured the output, but I'm not sure of the value of those short delays. The trace was very unstable, and there was more going on that you can see in the image.

[ESP_igrr]

That looks about the same way the trace I have attached to the previous post.

Now that you mention that the period is 2, I think I know where the problem comes from. Your code switches between two duty cycles, at 2 second intervals: 8000 and 0.
8000 is very close to 8191, so your scope may be just not showing the short negative pulses, and the line appears about the same as it would be with 100% duty cycle (8192 value). Then when you set duty cycle to zero, you naturally get constant low value.

This is how your original example (with ledc_update added) looks like on my LA at large time scale:

Screen Shot 2017-03-01 at 15.07.40.png (27.29 KiB) Viewed 13435 times

This is smaller time scale, notice the width of the negative pulse. Is it possible that your scope somehow doesn't show this narrow pulse?

Screen Shot 2017-03-01 at 15.04.02.png (40.16 KiB) Viewed 13435 times

[murray_lang]

The scope does not integrate. If there was a PWM signal, at that time base there would be a thick fuzzy black line 3v high across the screen regardless of the duty cycle. It's DC on those pins at all time bases. I don't normally have the scope on such a slow sweep. It's necessary in this case to see what's happening.

Murray

[ESP_igrr]

Okay, in that case I can't really think of any other reason for this behavior. I did a test on four boards, both using ESP-WROOM32 modules and bare chips, both rev 0 and rev 1 chips, and I see exactly the same behavior as in the traces I have posted above.

Maybe someone else can try this code and share what they see.

[murray_lang]

Actually I lied about the thick line regardless of duty cycle. That would be true for an old "CRO", but not quite a digital one. Still, to demonstrate what I mean, I have attached two pictures of my scope looking at the PWM signal from my ESP8266. Both are with a duty cycle of around 25%. One is 1s/div. The other is at 5ms/div.

This is what I should be seeing on the ESP32. If I didn't have the same result on two different modules, then I would thing there was a fault with the module.

[rudi ;-)]

Maybe someone else can try this code and share what they see.

hi ivan

your code looks on DevKitC V2
Menuconfig ESP32 specific: 240 MHz

unfiltered:

pwm_test.jpg (110.42 KiB) Viewed 13428 times

statistic:

pwm_test_detailed.jpg (135.79 KiB) Viewed 13427 times

statistic and 5v:

pwm_test_detailed_5v.jpg (130.05 KiB) Viewed 13426 times

hope this helps

best wishes
rudi

[murray_lang]

Since it looked to me very much like a timing issue - somewhere - I wanted to see what happened if I changed the clock speed setting in menuconfig. So I changed the setting from the default 240MHz to 160MHz and, lo and behold, PWM has burst into life.

I don't know yet if my module is in fact operating at 160MHz, or whether it is now working simply due to the math in the firmware, but at least I /we now know where to start looking.

Regards,
Murray

[rudi ;-)]

Menuconfig ESP32 specific: 240 MHz

first part code

Code: Select all

ledc_set_duty(LEDC_HIGH_SPEED_MODE, LEDC_CHANNEL_0, 8000);
ledc_update_duty(LEDC_HIGH_SPEED_MODE, LEDC_CHANNEL_0);
vTaskDelay(2);

pwm_test_detailed_1v_first_part_code_-8000-.jpg (127.86 KiB) Viewed 13423 times

second part code:

Code: Select all

ledc_set_duty(LEDC_HIGH_SPEED_MODE, LEDC_CHANNEL_0, 2047);
ledc_update_duty(LEDC_HIGH_SPEED_MODE, LEDC_CHANNEL_0);
vTaskDelay(2);

pwm_test_detailed_1v_second_part_code_-2047-.jpg (128.45 KiB) Viewed 13423 times

hope this helps

best wishes
rudi

[rudi ;-)]

I wanted to see what happened if I changed the clock speed setting in menuconfig. So I changed the setting from the default 240MHz to 160MHz and, lo and behold, PWM has burst into life.

first part of code
Menuconfig ESP32 specific: 160 MHz

pwm_test_detailed_1v_first_part_code_-8000-_menuconfig_160MHz.jpg (132.01 KiB) Viewed 13420 times

second part of code
Menuconfig ESP32 specific: 160 MHz

pwm_test_detailed_1v_second_part_code_-2047-_menuconfig_160MHz.jpg (134.27 KiB) Viewed 13420 times