ESP8285 gpio 9 & gpio 10 interrupt

[twanek]

Hardware

Hardware: ESP8285 (sonoff 4ch v2.0)
Core Version: 2.3.0 - 2.4.0
Arduino IDE: 1.8.4

Settings in IDE

Module: Generic ESP8285 Module
Flash Size: 1MB
CPU Frequency: 80Mhz
Upload Using: SERIAL

Sketch

void setup()
{
      attachInterrupt(digitalPinToInterrupt( 0), button1ISR, FALLING);  // button 1
      attachInterrupt(digitalPinToInterrupt( 9), button2ISR, FALLING);  // button 2
      attachInterrupt(digitalPinToInterrupt(10), button3ISR, FALLING);  // button 3
      attachInterrupt(digitalPinToInterrupt(14), button4ISR, FALLING);  // button 4
}

Problem description

hello!

i have a sonoff 4ch, pcb v2.0 board (ESP8285). i have replaced the stock firmware with custom, using the arduino ide.

i would like to set up interrupts for each button gpio. with the above setup, button 1 and button 4 works perfectly, however, button 2 and button 3 does not work. it seems that the interrupt is never executed, although i've checked with my multimeter that gpio9 and gpio10 are high, and is going low when i press the respective button.

what could be the reason for this? unfortunately i can not find a good pinout diagram for this esp8285, all the sites i've read says that all pins have interrupt function, except gpio16.

or something is not fully implemented in the arduino core, regarding digitalPinToInterrupt() function?
but than why works the same function for gpio0 and gpio14? i'm a bit confused regarding this.

thank you!

[twanek]

@igrr , please, could you look into this issue?

[twanek]

@igrr , based on some discussion on other forum, i've found the solution:

because there is no dedicated core for 8285, the same 8266 is used, and pins 9 and 10 are disabled by default. i have edited this file:

C:\Users\wanek\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.0-rc1\cores\esp8266\core_esp8266_wiring_digital.c

at line 166 there is this function:

void initPins() {
  //Disable UART interrupts
  system_set_os_print(0);
  U0IE = 0;
  U1IE = 0;

  for (int i = 0; i <= 5; ++i) {
    pinMode(i, INPUT);
  }
  // pins 6-11 are used for the SPI flash interface
  for (int i = 12; i <= 16; ++i) {
    pinMode(i, INPUT);
  }

  ETS_GPIO_INTR_ATTACH(interrupt_handler, &interrupt_reg);
  ETS_GPIO_INTR_ENABLE();
}

i have added these lines, and its working:

void initPins() {
  //Disable UART interrupts
  system_set_os_print(0);
  U0IE = 0;
  U1IE = 0;

  for (int i = 0; i <= 5; ++i) {
    pinMode(i, INPUT);
  }
  
  // pins 6-11 are used for the SPI flash interface (actually pins 9 and 10 are usable as gpio on esp8285)
  
  pinMode( 9, INPUT);
  pinMode(10, INPUT);

  for (int i = 12; i <= 16; ++i) {
    pinMode(i, INPUT);
  }

  ETS_GPIO_INTR_ATTACH(interrupt_handler, &interrupt_reg);
  ETS_GPIO_INTR_ENABLE();
}

but i have to find a way how to control the mcu type from my sketch, because in this current way it will crash if i will use an esp8266 board. i wonder should this feature be integrated to the official core?

thanks!

[devyte]

Does setting those 2 pins to INPUT inside setup() not work?

[twanek]

actually, i didn't tried it.
but afaik, normally one don't have to set a pin as input before using as interrupt. i didn't set gpio 0 nor 14 to input, and they are still working as expected.

[devyte]

@twanek did it work?

[twanek]

still didn't tried, because:

• i don't think it could work (because of the reasons mentioned in my above post)
• was busy with other things
• found a workaround for this, reccomended by a friend on blynk forum:

Find esp8285.build.board=ESP8266_ESP01 definition in boards.txt file. Change the generic end of line from ESP8266_ESP01 to something unique like ESP8285rev1. Save the file.

Then in "core_esp8266_wiring_digital.c" modify your code to:

#ifdef ARDUINO_ESP8285rev1
  pinMode( 9, INPUT);
  pinMode(10, INPUT);
#endif

Note the Arduino_ prefix before your new "ESP8285rev1". All boards are prefixed with Arduino_.
Nothing required in your sketch as it should only make pins 9 and 10 available when you compile for the ESP8285 board.

this works perfectly for me and others on the forum.

[devyte]

@twanek All you are doing is setting the pins as INPUT as well. The only difference is that you are doing it during the startup sequence, and that is what is worth understanding.
I was looking at using gpio10 myself, on an ESP12, and was unaware that interrupts probably won't work on it.
I think this is worth pursuing, and not just as an additional board.

Do you have a link to specs (i.e.: pinouts, schematics) for the specific board you are using? I just took a quick look, and it seems there are different variants.

[twanek]

• ok, you convinced me, i will give it a try the way you reccomend and check if it works :)

• pinout and schematic about this board you can find on itead website (look at my first post).

• i'm not expert in this, but afaik pins 9 and 10 are not usable on esp8266, because they are used by the external flash. as esp8285 has the flash integrated, it needs less pins to work, and this is why 9 and 10 are actually usable. but maybe i'm wrong.

[twanek]

this is how the mcu looks like. it is nothing special, a standard esp8285 chip, with pcb antenna.

[twanek]

it says:
ESP8285
482016
P13461 (this line is barely visible, so maybe it is not correct)

based on the official schematic, gpio 9 and gpio 10 are hooked up to the button 2 and 3, and are pulled high via 10k resistors. nothing special.

[devyte]

@twanek pins 9 and 10 are reported to work with interrupts in #2257 . Perhaps you should discuss with @kriswiner directly.

[twanek]

hi, thank for the report!

by the time, i tried to set as input directly from the setup sketch, as you mentioned @devyte , indeed it worked!

however, in the long run tests it appeared some very strange issues using the gpio 9 and 10 pins on esp8285! sorry for such a long post, but for better understanding the problem i thought it is necessary to explain the details:

i have a bigger blynk project for a hotel automation, where ~15 sonoff units are used. there are several th10 units (esp8266 based) and around five ch4 units (esp8285 based).

i have developed a generic firmware for all kind of sonoff units. just have to define the sonoff type before uploading, than the firmware knows which gpio pins to use on which models.

so, basically the same firmware is running on all the th10 and ch4 models. the th10 (esp8266 based) units are working flawlessly since 2017 august, no problem at all.

but with the ch4 (esp8285 based) units i have a very strange and big problem:

after random periods of time (between 4 hours and 4 weeks) suddenly all the data is lost from the epprom.

initially, i designed the firmware to store auth token, wifi passwords, sonoff model, relay states, etc in eeprom, thus i can update remotely (ota) a generic firmware to all sonoff units, when changes needed.

at the beginning, when one of the 4ch units couldn’t connect to the blynk server anymore - after some investigation - i’ve discovered that all the eeprom was cleared (value: 255) on that unit. thus, it had no token and wifi password to connect.

back then, because i’ve could not find out the cause, and the system had to be functional asap, i modified the firmware to store the important data also hardcoded in the code - not just in eeprom. this way, even if the eeprom data was lost, the device could function continually.

but after a while, other 4ch units begin to have similar issues, even worse: i figured out that not only the eeprom data, but also sometimes the firmware was missing on them (the eeprom and firmware is actually stored on the same flash chip in the esp ?).

after re-uploading the firmware on those units, they again work normally for a random period, so it is definitely not a permanent hardware damage.

i also observed, that this issue happening only on the esp8285 (4ch) units, the esp8266 (basic, th10, th16, etc) are working without a single issue, even after several months.

the main difference between esp8285 and esp8266 mcu is that the 85 has built in (1Mb?) flash in the mcu, and the 66 uses external (discrete), flash chip. i have a feeling that the problems are caused because of this difference in flash handling…

by design, the sonoff 4ch (esp8285) uses 2 gpio pins that are normally not accessible on the esp8266. this was discussed in this topic, earlier.

i have tried so far various esp cores (2.3, 2.4rc1, 2.4rc2), various arduino ide versions, on 4 VERY different batch ch4 units, but all presented the same behaviour: after some random time, the content of eeprom is lost, and sometimes the firmware is corrupted.

the eeprom content i can check for sure, by uploading a sketch and reading all the addresses. on the affected units they are all blank (255). on the working units i can retrieve the token and other data.
so far i couldn’t identify what inits this, it seems that it does not related to:

• restarting the device
• pushing the physical buttons
• loosing / reconnecting to wifi
• cycling the relay buttons / relays (from app or hw)
• tried different power sources
• tried 4-5 different sonoff ch4 units (from different batch), so i guess the problem is not hw related

i know it is not easy to help in this case, but any hints / directions would be great!

so far, i have no idea how / what to begin to debug (the whole firmware has ~1500 lines + the standard libs required by blynk, http, ota, wifimulti, etc).

edit: i upload the sketch using arduino ide, settings: dout, 1M (64k spiffs), 80mhz, 115200 baud

[twanek]

in last days i’ve made some further investigation and tend to think that those anomalies are somehow related to using gpio 9 and 10 as interrupts.

currently i’ve disabled completely those pins (not configured as interrupt, neither as input), and uploaded this version to all 4ch sonoff.

this caused, of course, that physical buttons 2 and 3 will not work on the hardware, but the client said it doesn’t really matters, because he always uses the app for controling the relays.

because i can’t deliberately ignite this issue, i will have to wait several weeks / months and see if the issue happens again. (so far 1 week passed, and none of the units had any issue. they are online and used 24/7)

if i will be convinced that it works ok this way, i will try to setup gpio 9 and 10 as simple input (without interrupt) and wait / see if it works. i will have to write a separate function for those 2 buttons to work without interrupt.

i've read lots of forums regarding this issue, and everywhere it is stated that using gpio 9 and 10 on esp8266 will surely cause crashes, wdt resets, etc.

but no good info can be found about those pins for the esp8285, and afaik, because of the built in flash uses less pins, pins 9 and 10 should be free to use...

[kriswiner]

No idea, I just confirmed that interrupt on pin 9 works fine. We have used the ESP8285 (not the EEPROM, which is emulated, of course) for all kinds of tasks and haven't had any trouble. Perhaps with the somewhat limited flash of the ESP8285 it would be better to use a dedicated EEPROM?

…

On Mon, Jan 8, 2018 at 10:35 AM, twanek ***@***.***> wrote: hi, thank for the report! by the time, i tried to set as input directly from the setup sketch, as you mentioned @devyte <https://github.com/devyte> , indeed it worked! however, in the long run tests it appeared some very strange issues using the gpio 9 and 10 pins on esp8285! sorry for such a long post, but for better understanding the problem i thought it is necessary to explain the details: i have a bigger blynk project for a hotel automation, where ~15 sonoff units are used. there are several th10 units (esp8266 based) and around five ch4 units (esp8285 based). i have developed a generic firmware for all kind of sonoff units. just have to define the sonoff type before uploading, than the firmware knows which gpio pins to use on which models. so, basically the same firmware is running on all the th10 and ch4 models. the th10 (esp8266 based) units are working flawlessly since 2017 august, no problem at all. but with the ch4 (esp8285 based) units i have a very strange and big problem: after random periods of time (between 4 hours and 4 weeks) suddenly all the data is lost from the epprom. initially, i designed the firmware to store auth token, wifi passwords, sonoff model, relay states, etc in eeprom, thus i can update remotely (ota) a generic firmware to all sonoff units, when changes needed. at the beginning, when one of the 4ch units couldn’t connect to the blynk server anymore - after some investigation - i’ve discovered that all the eeprom was cleared (value: 255) on that unit. thus, it had no token and wifi password to connect. back then, because i’ve could not find out the cause, and the system had to be functional asap, i modified the firmware to store the important data also hardcoded in the code - not just in eeprom. this way, even if the eeprom data was lost, the device could function continually. but after a while, other 4ch units begin to have similar issues, even worse: i figured out that not only the eeprom data, but also sometimes the firmware was missing on them (the eeprom and firmware is actually stored on the same flash chip in the esp ?). after re-uploading the firmware on those units, they again work normally for a random period, so it is definitely not a permanent hardware damage. i also observed, that this issue happening only on the esp8285 (4ch) units, the esp8266 (basic, th10, th16, etc) are working without a single issue, even after several months. the main difference between esp8285 and esp8266 mcu is that the 85 has built in (1Mb?) flash in the mcu, and the 66 uses external (discrete), flash chip. i have a feeling that the problems are caused because of this difference in flash handling… by design, the sonoff 4ch (esp8285) uses 2 gpio pins that are normally not accessible on the esp8266. this was discussed in this topic, earlier. i have tried so far various esp cores (2.3, 2.4rc1, 2.4rc2), various arduino ide versions, on 4 VERY different batch ch4 units, but all presented the same behaviour: after some random time, the content of eeprom is lost, and sometimes the firmware is corrupted. the eeprom content i can check for sure, by uploading a sketch and reading all the addresses. on the affected units they are all blank (255). on the working units i can retrieve the token and other data. so far i couldn’t identify what inits this, it seems that it does not related to: - restarting the device - pushing the physical buttons - loosing / reconnecting to wifi - cycling the relay buttons / relays (from app or hw) - tried different power sources - tried 4-5 different sonoff ch4 units (from different batch), so i guess the problem is not hw related i know it is not easy to help in this case, but any hints / directions would be great! so far, i have no idea how / what to begin to debug (the whole firmware has ~1500 lines + the standard libs required by blynk, http, ota, wifimulti, etc). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3549 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qtrBsjnQBtANM0HhGPvwXk6Lb6Ahks5tIl_ggaJpZM4PCyEG> .

[twanek]

thanks for the reply!

Perhaps with the somewhat limited flash of the ESP8285 it would be better
to use a dedicated EEPROM?

i do not know what could be the advantages / disadvantages using emulated / dedicated eeprom.
but i use exactly the same firmware on the th10 units, which use esp8266 + 1Mb flash (same size as esp8285), and never had any issue using the eeprom.

[devyte]

@twanek This issue covers using pins 9 and 10 as interrupt, and I think we can establish that they work as interrupt. BTW, don't forget that your ISRs need to have the ICACHE_RAM_ATTR keyword.

About the eeprom thing, please investigate further, especially the schematic of your device, to see if pins 9/10 are connected in some odd way to something. I seem to remember that using them required cutting a connection on the PCB somewhere, although I could be confusing this with some 8266 board. If you are absolutely sure that they should work as-is for your device, and they don't, then please open a new issue for that. It's always possible that the issue is not with the pins or ISR, but somewhere else.

Closing this as resolved.