wdt reset when using pwm at high frequency and wifi about esp8266_new_pwm

[StefanBruens]

Most probably you have an interrupt rate the module is not able to handle.

• The PWM creates 4 interrupts per cycle (All ON, GPIO12 OFF, GPIO 13 OFF, GPIO14 OFF), and the overhead is 3.5us per interrupt (3.3us are spent in ROM code) => 14us
• Each PWM cycle is 255 * 0.2us => 51us
• CPU is used 25% by PWM alone

Do you really need a PWM frequency of 20kHz? If not, multiply both PWM period and duty with the same constant, e.g. 10 or 20.

[nepeee]

I want to drive four brushed motors with high enough frequency that cant be heard by the human ears. The project that i'm working on is a simple quadcopter controlled via 802.11 custom data frames without resend and ack.

Basically three main functions that must be implemented for this:

1. The 802.11 one way radio communication based on wifi promiscuous mode and null data pockets filtered with the wifi_promiscuous_set_mac sdk function. This is currently working, the esp based rc remote and the quad can send/receive about 1500-2000 packet per second, the copter only needs about 50 pocket/second for the smooth control.
2. ~250hz main loop that reads an i2c gyroscope and calculates pids for the motor control. This is implemented but not tested yet.
3. pwm for the 4 motors

I don't understand whats causing the wdt resets when 75% CPU time is available for the wifi promiscuous mode.

[StefanBruens]

Regarding the PWM frequency:
Typical brushed micro motors run at 18000-24000 RPM loaded, or 300 to 400 Hz. Given two blades, you end up in the most sensitive range of human hearing. You won't hear the motor pwm, you will hear the propellers.
So reduce the PWM frequency to 2kHz. You should also use an RC or better LC filter to remove voltage ripples and to protect the ESP from the voltage spikes from the motor.

Regarding the watchdogs:

• Do you have PWM_DEBUG set to 1? The debug output uses a lot of time (relatively).
• How often do you call pwm_start()? pwm_start() is quite heavy, about 2000 instructions per call. Calling it from the control loop at 250Hz is fine, but don't do it much more often.
• Do you see the watchdogs even when the PWM is set to 0 or 100% on all channels?

[nepeee]

I accidentally found what coursing the problem :)
If the wifi is initialized before the pwm everything is works fine!

After that the wdt resets is disappeared i tried with the receiver code, 1700 pocket/second is received while the pwm is on(4 channels, ~20KHz, 255 period) and its worked fine. The only thing that was i changed is the interrupt mode to nmi because i got some jitter on the pwm signals.

Answers for the questions:

• Do you have PWM_DEBUG set to 1? The debug output uses a lot of time (relatively).
  No.
• How often do you call pwm_start()? pwm_start() is quite heavy, about 2000 instructions per call.
  Only once for initialization.
• Do you see the watchdogs even when the PWM is set to 0 or 100% on all channels?
  With 0 and 100% no watch dog resets, with only one channel at 50% the wdt resets comes back.

Stacktrace for the resets:
Exception (0):
epc1=0x4020101c epc2=0x00000000 epc3=0x4000430a excvaddr=0x00000000 depc=0x00000000

ctx: sys
sp: 3ffedec0 end: 3fffffb0 offset: 01a0

stack>>>
3ffee060: 00000000 00000000 00000000 00000000
....
ets Jan 8 2013,rst cause:4, boot mode:(1,7)

wdt reset
SDK version: V1.5.3_16_04_16

Thanks for your support and the code, now i could make the code for the hacky copter :)

[StefanBruens]

So the watchdogs only happen if you initialize the Wifi with the PWM already running?

Maybe the initialization code uses the FRC1 interrupt and can not cope with it being used for other things. But thats not something I can do anything about, as the interrupt registration function is part of the closed SDK code, as well as the Wifi initialization, so I will close this issue.