Ahhh! It must be my amateur prototype circuit wiring. Negligent absence of bypassing. Ground bounce etc.

Issue closed, I think.

Murray

OK, so what I can gather is that the "CPU frequency" setting in menuconfig actually changes the clock speed of the CPU by selecting multipliers/dividers applied to the 40MHz crystal input. I initially though that it was something that needed to be configured based on the speed set by some other ...

Sorry fellas,

I added nvs_flash_init() to one of my tasks by mistake instead of main. Tired and rushing.

All good now.

Many thanks,
Murray

Hi Neil,

The code was working for some time as is, and I ran make menuconfig (I was forced to by the SDK update anyway). I'll try erasing the flash.

Hi iggr,

I tried adding nvs_flash_init() when I remembered about the new PHY nvs param storage setting, but that didn't fix it. It's late here now ...

Hi all,

I have been successfully using WiFi for some time, but with the latest SDK I now see:
W (1031) wifi: wifi nvs_open fail ret=4353

E (1031) wifi: wifi_init 1191 ret=4353
assertion "0 && "esp_wifi_init(&cfg)"" failed: file "/home/murray/Robotics/Weta/
vm/weta-esp/weta-esp32/main/./main.c ...

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 ...

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 ...

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 ...

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 ...

Thanks iggr

That explains the difference in behaviour between the above code and my previous tests. However, remember that I tried the ledc example verbatim.

Anyway, I added the ledc_update_duty() calls to the simple test above and I am back to the original problem. Scope trace is attached. Note ...