ESP8266 Developer Zone

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-11-02T23:39:54+08:00

I have the same problem using NON-OS 2.0
Can anyone tell me how to fix it

Statistics: Posted by beyondhong — Wed Nov 02, 2016 11:39 pm

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-09-12T21:24:23+08:00

I switched to my own implementation now (for various reasons), so the problem is not relevant anymore.

Statistics: Posted by eriksl — Mon Sep 12, 2016 9:24 pm

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-07-23T05:09:41+08:00

I note you are using RBOOT - are you now having issues with RBOOT on new devices from around 1.54 onwards? I am having issues - the software is not starting up in the right order and sometimes not at all - all started around 1.54

eriksl wrote:
It shouldn't be too hard to reproduce. Connect PWM channels to io 14 and io 15, activate one of them (or both) and wait.

Statistics: Posted by scargill — Sat Jul 23, 2016 5:09 am

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-07-16T00:26:58+08:00

I'd suggest that you explicitly add the SDK function to feed the watchdog timer in those parts of the code that might be causing the processor to loop for too long. That should reduce your chances of running into random resets like this.

Statistics: Posted by Guest — Sat Jul 16, 2016 12:26 am

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-07-15T16:53:56+08:00

Hi Erik!
I'm so sorry that ESP engineer could not reproduce the problem, either.

Code:

/*
 * ESPRSSIF MIT License
 *
 * Copyright (c) 2015 
 *
 * Permission is hereby granted for use on ESPRESSIF SYSTEMS ESP8266 only, in which case,
 * it is free of charge, to any person obtaining a copy of this software and associated
 * documentation files (the "Software"), to deal in the Software without restriction, including
 * without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense,
 * and/or sell copies of the Software, and to permit persons to whom the Software is furnished
 * to do so, subject to the following conditions:
 * 
 * The above copyright notice and this permission notice shall be included in all copies or
 * substantial portions of the Software.
 * 
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
 * FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
 * COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
 * IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 *
 */

#include "esp_common.h"
#include "../sample_lib/wifi/wifi_test.h"
#include "uart.h"

#include "gpio_test.h"


/*Definition of GPIO PIN params, for GPIO initialization*/

#define PWM_4_OUT_IO_MUX PERIPHS_IO_MUX_MTDI_U
#define PWM_4_OUT_IO_NUM 12
#define PWM_4_OUT_IO_FUNC  FUNC_GPIO12

#define PWM_1_OUT_IO_MUX PERIPHS_IO_MUX_MTDO_U
#define PWM_1_OUT_IO_NUM 15
#define PWM_1_OUT_IO_FUNC  FUNC_GPIO15

#define PWM_2_OUT_IO_MUX PERIPHS_IO_MUX_GPIO4_U
#define PWM_2_OUT_IO_NUM 4
#define PWM_2_OUT_IO_FUNC  FUNC_GPIO4

#define PWM_3_OUT_IO_MUX PERIPHS_IO_MUX_MTMS_U
#define PWM_3_OUT_IO_NUM 14
#define PWM_3_OUT_IO_FUNC  FUNC_GPIO14

//#define PWM_4_OUT_IO_MUX PERIPHS_IO_MUX_GPIO5_U
//#define PWM_4_OUT_IO_NUM 5
//#define PWM_4_OUT_IO_FUNC  FUNC_GPIO5


uint32 io_info[][3] = { 
    {PWM_1_OUT_IO_MUX,PWM_1_OUT_IO_FUNC,PWM_1_OUT_IO_NUM},
    {PWM_2_OUT_IO_MUX,PWM_2_OUT_IO_FUNC,PWM_2_OUT_IO_NUM},
    {PWM_3_OUT_IO_MUX,PWM_3_OUT_IO_FUNC,PWM_3_OUT_IO_NUM},
    {PWM_4_OUT_IO_MUX,PWM_4_OUT_IO_FUNC,PWM_4_OUT_IO_NUM}
};

void user_init(void)
{
   uint32 duty[3]={0,0,0},i;


      pwm_init(1000,duty,4,io_info);//1000us
      pwm_set_duty(20,0);/*20us */
      pwm_set_duty(10,1);/*10us This is IO4*/
      pwm_set_duty(15,2);/*15us */
      pwm_set_duty(5,3);/*5us */
      pwm_start();
   

}

Statistics: Posted by ESP_Yuhao — Fri Jul 15, 2016 4:53 pm

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-07-08T02:53:54+08:00

eriksl wrote:
This is not "production" stuff, and for the moment it's not a problem because I can fall back to the older SDK version.

But in future SDK versions, I really hope this will get fixed, so I can make use of new features.

hi erik

not sure - my unthink vision
15 min = 15 * 60 = 900 / 6.5 ns ( 0,0000000065 ) = 138461538461,5385 ( clk )
duty? ( 10 ) / 10
freq? ( 10 ) / 10
intval? ( 3 ) / 3
total 15 min ..= diff 3 sec ..

try to use/add

Code:


while(1) {

// try this..
system_soft_wdt_feed();

// your pwm call
}

perhabs it helps

best wishes
rudi

Statistics: Posted by rudi — Fri Jul 08, 2016 2:53 am

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-07-08T00:58:27+08:00

This is not "production" stuff, and for the moment it's not a problem because I can fall back to the older SDK version.

But in future SDK versions, I really hope this will get fixed, so I can make use of new features.

Statistics: Posted by eriksl — Fri Jul 08, 2016 12:58 am

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-07-06T19:58:45+08:00

Hello,

I could not reproduce the problem.
I'd suggest that you use an SDK version released just before the latest one available for stability reaons in end products.
I'll let you know if I find a solution to this or if I am able to reproduce the issue.

One thing you could try is wipe the flash clean and reprogram init_data and blank sectors and firmware. Sometimes that sorts some unexplained problems.

Statistics: Posted by Guest — Wed Jul 06, 2016 7:58 pm

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-07-06T02:21:19+08:00

Hello Pradik.

I have configured IO 14 and IO 15 for PWM but in practise only IO 14 is used. So both IO 14 and IO 15 are in the gpio_info_t struct array, but only IO 14 has a duty cycle > 0 normally.

I can reconfigure, so IO 15 isn't included into the struct array at all, so the struct array only has one member -> IO 14? Should that make a difference?

I have been using up to four PWM channels in the past and that was never a problem, btw.

Statistics: Posted by eriksl — Wed Jul 06, 2016 2:21 am

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-07-04T12:12:23+08:00

Hello,

If you use only GPIO14 for PWM, does it still cause a watchdog reset after some time?

I'll see if I can reproduce the issue. What hardware are you using?

Statistics: Posted by Guest — Mon Jul 04, 2016 12:12 pm

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-07-03T15:22:03+08:00

It shouldn't be too hard to reproduce. Connect PWM channels to io 14 and io 15, activate one of them (or both) and wait.

Statistics: Posted by eriksl — Sun Jul 03, 2016 3:22 pm

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-07-01T22:12:47+08:00

That's a bit difficult, because it's part of a huge project (image is > 256 kbytes, mostly actual code). It also includes an alternative boot loader (rboot) which makes OTA actually possible in this case. It's here if you still want to try: http://github.com/eriksl/esp8266-universal-io-bridge

But, the PWM code like it is now, has been working fine in several SDK releases, for at least half a year, maybe longer. Only with the last update of the SDK the crashing started. When I go back one SDK version (or more), recompile+link everything, the problem is completely gone, exactly the same code and the same flow.

Statistics: Posted by eriksl — Fri Jul 01, 2016 10:12 pm

Re: NON-OS 1.5.4 (16_05_20) PWM bug

2016-06-20T09:26:50+08:00

Hi,

Can you provide your test code ? We will have a try.

Thanks for your interest in ESP8266 !

Statistics: Posted by ESP_Faye — Mon Jun 20, 2016 9:26 am

NON-OS 1.5.4 (16_05_20) PWM bug

2016-06-19T18:24:57+08:00

If you use PWM on this version, the ESP will restart in about 15 minutes (exact time will vary) due to "hardware watchdog timeout". If you switch to one version earlier (ESP8266_NONOS_SDK_V1.5.3_16_04_18) the problem is gone.

I am very grateful for the IRAM cleanup btw. Gained about 4 Kbytes from 1.5.2 to 1.5.3.

Statistics: Posted by eriksl — Sun Jun 19, 2016 6:24 pm