2.3.3
Version 1 of library was working fine. Today i updated to v 2.3.3 and i checked ir firing and my esp is crashing everytime it fires a code (right after firing the code i think).
I am firing this with AsyncWebserver and not in the main loop. So i fire IR Code in the callback function after recieving http request.
I know that there is a possibility that esp crashes if delay() is very long. But it was working fine in previous version(Version 1 i guess, in library.json no version is mentioned).
And i also added this code for safety
ESP.wdtDisable();
irsend.sendLG((unsigned long)actCode,length);
ESP.wdtFeed();
ESP.wdtEnable(5000);
Can anybody point out to me whats wrong here.. ?
I am also adding stack trace from esp exception decoder
Exception 9: LoadStoreAlignmentCause: Load or store to an unaligned address
Decoding 94 results
0x40104de0: ets_timer_setfn at ?? line ?
0x40106a34: delayMicroseconds at /Users/iamnostar/Library/Arduino15/packages/esp8266/hardware/esp8266/2.4.0/cores/esp8266/core_esp8266_wiring.c line 83
0x40221ebc: IRtimer::reset() at /Users/iamnostar/Documents/Arduino/libraries/IRremoteESP8266/src/IRtimer.cpp line 26
0x4010500c: ets_timer_arm_new at ?? line ?
0x40221bb4: IRsend::mark(unsigned short) at /Users/iamnostar/Documents/Arduino/libraries/IRremoteESP8266/src/IRsend.cpp line 466
0x40201678: delay at /Users/iamnostar/Library/Arduino15/packages/esp8266/hardware/esp8266/2.4.0/cores/esp8266/core_esp8266_wiring.c line 46
0x40221a8c: IRsend::ledOff() at /Users/iamnostar/Documents/Arduino/libraries/IRremoteESP8266/src/IRsend.cpp line 466
0x40221c1c: IRsend::space(unsigned int) at /Users/iamnostar/Documents/Arduino/libraries/IRremoteESP8266/src/IRsend.cpp line 466
0x40221e04: IRsend::sendGeneric(unsigned short, unsigned int, unsigned short, unsigned int, unsigned short, unsigned int, unsigned short, unsigned int, unsigned int, unsigned long long, unsigned short, unsigned short, bool, unsigned short, unsigned char) at /Users/iamnostar/Documents/Arduino/libraries/IRremoteESP8266/src/IRsend.cpp line 466
0x40238e79: pbuf_free_LWIP2 at /local/users/gauchard/arduino/arduino_esp8266/origin/tools/sdk/lwip2/builder/lwip2-src/src/core/pbuf.c line 1306
0x40222130: IRsend::sendLG(unsigned long long, unsigned short, unsigned short) at /Users/iamnostar/Documents/Arduino/libraries/IRremoteESP8266/src/ir_LG.cpp line 80
From the readme.md for Async Webserver:
"You can not use yield or delay or any function that uses them inside the
callbacks"
As of V2, there are delay() calls in most protocols send() routines.
Depending on what you're trying to do, you've got a few workarounds. Either
change the LG end of message gap to zero, or change the threshold in
https://github.com/markszabo/IRremoteESP8266/blob/master/src/IRsend.cpp#L155
to stop delay() calls.
The better approach is to not do the send in the callback. Eg. Set a flag
or add to a queue for the send request, and do the send(s) in the main loop.
On Tue., 13 Mar. 2018, 9:39 pm arihant daga, notifications@github.com
wrote:
Version/revison of the library used
2.3.3
Expected behaviorVersion 1 of library was working fine. Today i updated to v 2.3.3 and i
checked ir firing and my esp is crashing everytime it fires a code (right
after firing the code i think).
I am firing this with AsyncWebserver and not in the main loop. So i fire
IR Code in the callback function after recieving http request.
I know that there is a possibility that esp crashes if delay() is very
long. But it was working fine in previous version(Version 1 i guess, in
library.json no version is mentioned).
And i also added this code for safetyESP.wdtDisable();
irsend.sendLG((unsigned long)actCode,length);
ESP.wdtFeed();
ESP.wdtEnable(5000);Can anybody point out to me whats wrong here.. ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/markszabo/IRremoteESP8266/issues/430, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AMInDB8QmNFeX70X8i850QtA2R0Ziv_lks5td7AFgaJpZM4Soh4K
.
Now that I can see the stack trace, this reads more like a language use error/problem.
i.e. A google search of "Exception 9: LoadStoreAlignmentCause: Load or store to an unaligned address" indicates some issues with users using references to objects that no-longer exist. i.e. They (object) were on the stack, and then destroyed, then subsequently tried to be used.
I can't suggest anything more without seeing the real code etc.
TL;DR: I think you've got a coding problem based on that stack trace, not a WDT error etc. The delay thing _might_ be a red-herring. Try reducing your code to as simple as possible that still causes the issue, and post that code here. That process may help you see the cause of the error along the way.
How are you going with this?
@crankyoldgit Thank you for explaining this.. I dint get a chance to work on it again, so for now i just rolled back to the previous version, But i'll check this soon..
Friendly ping. How did you go?
Still caught up in other things. Will get back to it as soon as possible. :)
@crankyoldgit
Hi, I am sorry, I was gone long, was busy with other things.
Today i tried to fix it.
I changed the _delayMicroSeconds() function a little bit.
Turns out that we cannot call delay()in async Callbacks. But delaymicroseconds() goes just fine.
So i updated this code
delay(usec / 1000UL);
delayMicroseconds(static_cast<uint16_t>(usec % 1000UL));
to this one.
uint16_t wholes = usec / 1000UL;
while(wholes--){
delayMicroseconds(1000);
}
delayMicroseconds(static_cast<uint16_t>(usec % 1000UL));
Its working fine right now. I tested it with both sendRaw() and Other Protocol based Functions.
Do you think it's alright to do this ? or will it create any issue ?
If its alright, I can submit the PR.
An issue/feature request is probably best.
Thinking about it, we should set a flag or a compile-time option (i.e. a #define) for this sort of behaviour.
Giving up on using the delay() which feeds the watchdog timer is something that is not really best practice on the ESP8266, so it should be something that a user explicitly requests/configures. I don't want to cause WDT resets for people.
Also, probably best to use a modulus that is much higher than 1000, as each iteration through that loop may lose microseconds with the while/decrement statements.
@arihantdaga Can you please try out the new branch https://github.com/markszabo/IRremoteESP8266/tree/asyncweb-support and let me know if it fixes your issue? I've just added what I think will support what you want to do w.r.t. AsyncWebserver etc.
Per the new comments in IRremoteESP8266.h you'll need to set ALLOW_DELAY_CALLS to false for your situation.
Nice.. Thank you.
On Fri 4 May, 2018, 8:06 PM David Conran, notifications@github.com wrote:
@arihantdaga https://github.com/arihantdaga Can you please try out the
new branch
https://github.com/markszabo/IRremoteESP8266/tree/asyncweb-support and
let me know if it fixes your issue? I've just added what I think will
support what you want to do w.r.t. AsyncWebserver etc.Per the new comments in IRremoteESP8266.h you'll need to set PREFER_DELAY
to false for your situation.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/markszabo/IRremoteESP8266/issues/430#issuecomment-386621419,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEvvTPIVH1wpxFzLbotEzYLcltfTMYufks5tvGdjgaJpZM4Soh4K
.
Did the changes I made work for you?
Yeah. Working great.
On Mon, May 7, 2018 at 11:19 AM David Conran notifications@github.com
wrote:
Did the changes I made work for you?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/markszabo/IRremoteESP8266/issues/430#issuecomment-386963661,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEvvTIkvAO1WBr_Hw4Gg4DCfaSk4CCd6ks5tv-BagaJpZM4Soh4K
.
--
Regards
Daga Arihant
+91-9052110871
"Never let anybody tell you, you can't do something. "
Excellent. I'll mark this closed when the PR is merged in.
Merged in to the master branch. Closing this now.
FYI, the fix was included in the latest offical release of the library. (v2.4.1)