Esp32 Core version 3

[BorisKofman]

Fixes #2039

[NiKiZe]

Duplicate of #2040 / #2039 ?

But please provide an explanation if this has any improvements over the other.

[BorisKofman]

Feature:

Make IRremoteESP8266 compatible with IDF 5.x ESP32 Version 3

[BorisKofman]

@NiKiZe code is running on ESP32 S3 With ESP32 Version 3.0.4 without any errors

I will try to test with ESP32-DEV & ESP32-C6 this weak

[NiKiZe]

As I understand it, so is #2040, we are grateful for your PR. Just want to limit duplication if there already is a fully working implementation.

[BorisKofman]

Thanks @NiKiZe,
With #2040 I get error: timer is not enabled yet
I will try to test my Code with IDF 5.x and much Boards that I can
Currently tested "IDF 5.X" with S3.
Tomorrow will try with C6 and esp32-dev.
Then I will revert to ESP32 board version 2 to test again with S3 & DEV boards
Thanks!

[Jason2866]

#2040 is working perfectly fine.

[Buddy-Matt]

@Jason2866 - #2040 isn't working on the M5Stack NanoC6 under Arduino IDE. Have commented on the relevant PR

I'm able to decode my remote using this pull request

[BorisKofman]

@Jason2866 Tested with ESP32-C6 WROOM1, ESP32 WROVER and the code is working on Esp32 Core version 3.
Thanks!

[BorisKofman]

@NiKiZe @Jason2866 Thank you for feedback did the required changes
Thanks!

[Ks89]

oh wow, approved.
when do you expect to merge and release this?

[ivmbusiness]

Big thanks to @BorisKofman who did this PR. It works!
wonder why it is not merged and tagged...

[robertlipe]

wonder why it is not merged and tagged...

We should have sent this PR a birthday cake two days ago.

[robertlipe]

I last used the one that was in this PR: https://github.com/BorisKofman/IRremoteESP8266/tree/Espressif-version-3 I'll admit that in my Arduino3 branch, had simply disabled IR support for now. I really don't cae about anything beyond reading NEC and I'm pretty sure I can find a solution hat does a lot less that better fits. I'd looked at https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/rmt.html and when I looked at https://github.com/espressif/esp-idf/blob/fcae32885b0296b32044cb99ecbdc50d98dddb83/examples/peripherals/rmt/ir_nec_transceiver/main/ir_nec_transceiver_main.c#L154 with the thought that I recall only care about IR and receive, making most of this library just overhead to me, I figured I could probably just snip out the few dozen lines of that path and get a big part of the way there. But I've had other blocking issues and just haven't gotten back to it. And that doesn't help the people that DO need all that goes into this library. The https://github.com/Arduino-IRremote/Arduino-IRremote project does seem to be alive, so if you send them a PR or a help request, it might actually go somewhere.

…

On Tue, Sep 30, 2025 at 4:14 PM Jan-Petter Gundersen < ***@***.***> wrote: *JanPetterMG* left a comment (crankyoldgit/IRremoteESP8266#2144) <#2144 (comment)> *While waiting for this PR to get merged*, I was wondering if there are any good alternatives worth trying. I’ve looked through the network graph of forks, but none seem to clearly stand out as both up-to-date and maintained. If there is one I’ve overlooked, I’d really appreciate a pointer. 👍 In the meantime, I’ve tested a couple of different libraries: - Arduino-IRremote/Arduino-IRremote: Probably the closest match overall, but Arduino v3 support seems broken in the latest release. The last version that works does so with a alarming performance cost. - Another option I tried, a much smaller library, handled some protocols flawlessly, but failed to detect others even though they’re listed as supported. My main interest is in reliable support for the common protocols (Philips, Samsung, Sony, etc.). — Reply to this email directly, view it on GitHub <#2144 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD366TUUCJUMBMK2ZUED3VLXE7AVCNFSM6AAAAABNYYEXR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNJTHAZDSMRZG4> . You are receiving this because you commented.Message ID: ***@***.***>

[KingingWang]

I would like to ask whether this PR can function normally with esp-idf 5.5 and arduino3.0? Has anyone tested it? Thank you very much!

[sblantipodi]

@crankyoldgit Is there a planned release that will include the core 3 features added to the master branch?
thanks!!!!

[crankyoldgit]

Yes

[sblantipodi]

@crankyoldgit one question if possible.

acir.send(RETRY_NUM);

makes ESP32 to crash and reboot due to watchdog, this happens even if the RETRY_NUM is set to 1.

is there a solution to this problem?

[robertlipe]

Are you saying that's new after #2144 is applied? If you roll back to the Arduino 2 layer (this code SHOULD notice this and still build) does the crash stay or go? The Arduino3 layer changed some things (a lot of things) but for this project, it was almost entirely just changing function signatures on the timers to adapt to new arguments being unused, etc. The change that made rmtWrite() block shouldn't matter here as this code doesn't directly call that <https://docs.espressif.com/projects/arduino-esp32/en/latest/api/rmt.html>. https://docs.espressif.com/projects/arduino-esp32/en/latest/migration_guides/2.x_to_3.0.html#timer My own testing from long ago was limited to receiving. I'd probably try some brute force experimentation with https://github.com/crankyoldgit/IRremoteESP8266/blob/f66374d087d844184f69522ef296d3336fa052fb/src/IRsend.cpp#L114 just to see if there's a loop that's just a hair over the WDT expiration and maybe letting it reschedule another task instead of spinwaiting will stop it from barking. I'm traveling and can't get to hardware to help debug this. Finding the call stack of the hung thread is likely going to be a key. Can you get it in a debugger and identify where it's looping?

…

On Tue, Dec 16, 2025 at 3:20 AM Davide Perini ***@***.***> wrote: *sblantipodi* left a comment (crankyoldgit/IRremoteESP8266#2144) <#2144 (comment)> @crankyoldgit <https://github.com/crankyoldgit> one question if possible. acir.send(RETRY_NUM); makes ESP32 to crash and reboot due to watchdog, this happens even if the RETRY_NUM is set to 1. is there a solution to this problem? — Reply to this email directly, view it on GitHub <#2144 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD32PHG5QLMTRPP7HEET4B7FGDAVCNFSM6AAAAABNYYEXR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNJZGU3DQMZVGA> . You are receiving this because you commented.Message ID: ***@***.***>

[sblantipodi]

@robertlipe I don't think that the problem is caused by #2144, the problem is caused by Core 3 it self,
Arduino Core 3 does not like long functions that "block" the execution for a long time without resetting the watchdog.

not a big issue I think.

this loop is what causes the ESP to trigger the watchdog when the repeat param is big enough to trigger it.

void IRsend::sendSamsungAC(const uint8_t data[], const uint16_t nbytes,
                           const uint16_t repeat) {
  if (nbytes < kSamsungAcStateLength && nbytes % kSamsungAcSectionLength)
    return;  // Not an appropriate number of bytes to send a proper message.

  enableIROut(38);
  for (uint16_t r = 0; r <= repeat; r++) {
    // Header
    mark(kSamsungAcHdrMark);
    space(kSamsungAcHdrSpace);
    // Send in 7 byte sections.
    for (uint16_t offset = 0; offset < nbytes;
         offset += kSamsungAcSectionLength) {
      sendGeneric(kSamsungAcSectionMark, kSamsungAcSectionSpace,
                  kSamsungAcBitMark, kSamsungAcOneSpace, kSamsungAcBitMark,
                  kSamsungAcZeroSpace, kSamsungAcBitMark, kSamsungAcSectionGap,
                  data + offset, kSamsungAcSectionLength,  // 7 bytes == 56 bits
                  38000, false, 0, 50);                    // Send in LSBF order
    }
    // Complete made up guess at inter-message gap.
    space(kDefaultMessageGap - kSamsungAcSectionGap);
  }
}

in my case a repeat of 3 is enough to trigger the watchdog.

Adding something like
esp_task_wdt_reset();
inside that kind of loop may help solving the problem.

[robertlipe]

That's always been forbidden. I suppose if you were just on the edge before, something got rearranged in the scheduler and it's now being enforced. Long running things should be off in a thread of their own where they're free to be put to sleep. Code originally for 8-bit Arduinos that aren't multitasking (remember, you're almost always running inside a FreeRTOS environment) and running network stacks behind your back generally don't have to worry about such things. Likewise with stack usage. That's a thing you have to care about in ESP32-land where you can run wild on an Atmega. (Or as wild as you can get with 2k of ram or whatever...) As another experiment, you might try tossing a taskYIELD in that loop. That may break any strict timing requirements you have here, but it would give the system some breathing room to let other tasks run. Remember that the watchdog is a symptom, not a cause; if it's barking things like network and serial and bluetooth and ntp and other things are headed into the guard rails, too.

…

On Tue, Dec 16, 2025 at 5:35 AM Davide Perini ***@***.***> wrote: *sblantipodi* left a comment (crankyoldgit/IRremoteESP8266#2144) <#2144 (comment)> @robertlipe <https://github.com/robertlipe> I don't think that the problem is caused by #2144 <#2144>, the problem is caused by Core 3 it self, Arduino Core 3 does not like long functions that "block" the execution for a long time without resetting the watchdog. not a big issue I think. this loop is what causes the ESP to trigger the watchdog when the repeat param is big enough to trigger it. void IRsend::sendSamsungAC(const uint8_t data[], const uint16_t nbytes, const uint16_t repeat) { if (nbytes < kSamsungAcStateLength && nbytes % kSamsungAcSectionLength) return; // Not an appropriate number of bytes to send a proper message. enableIROut(38); for (uint16_t r = 0; r <= repeat; r++) { // Header mark(kSamsungAcHdrMark); space(kSamsungAcHdrSpace); // Send in 7 byte sections. for (uint16_t offset = 0; offset < nbytes; offset += kSamsungAcSectionLength) { sendGeneric(kSamsungAcSectionMark, kSamsungAcSectionSpace, kSamsungAcBitMark, kSamsungAcOneSpace, kSamsungAcBitMark, kSamsungAcZeroSpace, kSamsungAcBitMark, kSamsungAcSectionGap, data + offset, kSamsungAcSectionLength, // 7 bytes == 56 bits 38000, false, 0, 50); // Send in LSBF order } // Complete made up guess at inter-message gap. space(kDefaultMessageGap - kSamsungAcSectionGap); } } in my case a repeat of 3 is enough to trigger the watchdog. Adding something like esp_task_wdt_reset(); inside that kind of loop may help solving the problem. — Reply to this email directly, view it on GitHub <#2144 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD3Z4LAVWRLMZ4TUBFUL4B7VANAVCNFSM6AAAAABNYYEXR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNRQGA4TAMZYGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[crankyoldgit]

Have you set ALLOW_DELAY_CALLS to FALSE at all? Doing so can easily cause the WDT to enact a reset.

Normally the library (with ALLOW_DELAY_CALLS allowed/TRUE) will make a delay() call which is enough to reset the WDT (or it used to be under the previous framework). That is, any delay of 1000us or more, it will substitute a delay() call in, so as to play nice with everything.

e.g.

IRremoteESP8266/src/IRsend.cpp

Lines 111 to 142 in f66374d

	#if ALLOW_DELAY_CALLS
	/// An ESP8266 RTOS watch-dog timer friendly version of delayMicroseconds().
	/// @param[in] usec Nr. of uSeconds to delay for.
	void IRsend::_delayMicroseconds(uint32_t usec) {
	// delayMicroseconds() is only accurate to 16383us.
	// Ref: https://www.arduino.cc/en/Reference/delayMicroseconds
	if (usec <= kMaxAccurateUsecDelay) {
	#ifndef UNIT_TEST
	delayMicroseconds(usec);
	#endif
	} else {
	#ifndef UNIT_TEST
	// Invoke a delay(), where possible, to avoid triggering the WDT.
	delay(usec / 1000UL); // Delay for as many whole milliseconds as we can.
	// Delay the remaining sub-millisecond.
	delayMicroseconds(static_cast<uint16_t>(usec % 1000UL));
	#endif
	}
	}
	#else // ALLOW_DELAY_CALLS
	/// A version of delayMicroseconds() that handles large values and does NOT use
	/// the watch-dog friendly delay() calls where appropriate.
	/// @note Use this only if you know what you are doing as it may cause the WDT
	/// to reset the ESP8266.
	void IRsend::_delayMicroseconds(uint32_t usec) {
	for (; usec > kMaxAccurateUsecDelay; usec -= kMaxAccurateUsecDelay)
	#ifndef UNIT_TEST
	delayMicroseconds(kMaxAccurateUsecDelay);
	delayMicroseconds(static_cast<uint16_t>(usec));
	#endif // UNIT_TEST
	}
	#endif // ALLOW_DELAY_CALLS

Correction: It will only do that when there is a gap of at least kMaxAccurateUsecDelay uSeconds (16383us). Most protocols have a gap larger than that between repeats. So it's not a problem.

[crankyoldgit]

@crankyoldgit one question if possible.

acir.send(RETRY_NUM);

makes ESP32 to crash and reboot due to watchdog, this happens even if the RETRY_NUM is set to 1.

is there a solution to this problem?

Can you provide more context here? Which protocol are you using? Code snippet?

[crankyoldgit]

// Complete made up guess at inter-message gap.
space(kDefaultMessageGap - kSamsungAcSectionGap);

kDefaultMessageGap is 100000 and kSamsungAcSectionGap is 2886 .. which is 97144, which is WAY larger than 16383, so, unless you've turned off the ALLOW_DELAY_CALLS, it should be making a delay(97) every message, which should satisfy the WDT.

[sblantipodi]

Can you provide more context here? Which protocol are you using? Code snippet?

'll provide a pull request later if needed, forgot about it for now.
Core 3 is very sensitive to the watchdog, so long for loops don't play well with it.

In the meantime, I solved it by feeding the watchdog and calling yield() before:
acir.send(RETRY_NUM);