ETS_FRC_TIMER1_NMI_INTR_ATTACH does not work

[dkinzer]

I built a small application to test the use of the RTC Timer1 based on the example code hw_timer.c. The app works as expected if I use the normal interrupt (i.e. FRC1_SOURCE as defined in hw_timer.c). However, if I change it to use a NMI (i.e. NMI_SOURCE as defined in hw_timer.c) the app crashes, outputting garbage. Changing back to FRC1_SOURCE makes the app work again so it is clearly the use of ETS_FRC_TIMER1_NMI_INTR_ATTACH() that causes the problem.

I'm using the esp_iot_sdk_v1.2.0_15_07_03 SDK and I did have to create a prototype for NmiTimSetFunc() to get the code to compile as it is missing from the SDK includes. I used this:

Code: Select all

void NmiTimSetFunc(void (*handler)(void));

Can anyone suggest what I might be doing wrong or point me to a full working example that uses the Timer1 NMI?

[ESP_Faye]

Hi,

Thanks for your interest in Espressif Systems and ESP8266 !

Here is an example,

Code: Select all

#define REG_READ(_r) (*(volatile uint32 *)(_r))
#define WDEV_NOW()\
    REG_READ(0x3ff20c00)
static u32 tick_now2 = 0;
void   hw_test_timer_cb(void)
{
    static uint16 j = 0;
    j++;
   
    if( (WDEV_NOW() - tick_now2) >= 1000000 )
    {
    static u32 idx = 1;
        tick_now2 = WDEV_NOW();
        printf("b%u:%d\n",idx++,j);
        j = 0;
    }
    //hw_timer_arm(50);
}

typedef enum {
    FRC1_SOURCE = 0,   
    NMI_SOURCE = 1,   
} FRC1_TIMER_SOURCE_TYPE;
void ICACHE_FLASH_ATTR user_init(void)
{

        hw_timer_init(NMI_SOURCE,1);
        hw_timer_set_func(hw_test_timer_cb);
        hw_timer_arm(100);
}


[dkinzer]

Here is an example [...]

Thanks. That is the "test" code from the hw_timer.c example with the addition of two missing definitions. Building that test application produces the same result as my derived application - outputting garbage and WDT resets.

[ESP_Faye]

Hi,

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

Please notice that do not call “os_printf” in NMI timer callback，use “printf” instead.

[eriksl]

What is the difference then?

[dkinzer]

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

The user_main.c file is in the attached .zip file. Thanks.

[ESP_Faye]

Hi，

Please do not call “os_printf” in NMI timer callback，use “printf” instead.

If your problem is still unsolved, please feel free to let us know.

Thanks for your interest in ESP8266 !

[dkinzer]

Please do not call “os_printf” in NMI timer callback，use “printf” instead.

OK, I completely eliminated all printf-like functions. I am not at all surprised to find that the test app still does not work when using NMI_SOURCE but works fine using a regular interrupt. The new test code is attached.

[ESP_Faye]

Hi,

So sorry that we can not duplicate your problem. We tried your test code, it works fine.

Here is our test code and test log, please have a try.

Try it with baudrate 74880.

If your problem is still unsolved, please offer your entire project (esp_iot_sdk) and your test log.

[dkinzer]

If your problem is still unsolved, please offer your entire project.

I've attached a .zip file containing a simple makefile and the source code. The makefile uses the esptool-ck utility (lines 24 and 25 of the Makefile) to produce the image files from the ELF file. The code was compiled on a Windows 7 system using the v1.3.0 SDK. The makefile will probably need to be modified slightly to account for the installation directories of the compiler and SDK (lines 4 and 5 of "Makefile"). Beyond that, the makefile should build the app on either Windows or Linux.

In the .zip file, there are two subdirectories - "regInterrupt" and "nmiInterrupt" which contain the generated ELF file and image files for the regular interrupt build and the NMI build, respectively. The only difference between the two was changing the conditional on line 84 of user_main.c so that it uses either a normal interrupt or an NMI.

The images were flashed to an ESP8266 with a 512KB Flash chip and the "regInterrupt" version works exactly as expected while the "nmiInterrupt" version starts with a small amount of the normal boot-up output and then output garbage.

Thanks for looking into this. It's probably something simple but I don't see it. I believe that I've provided everything (other than the compiler, SDK and esptool-ck) to allow you to build exactly the same ELF and image files to confirm the observation.