Hi @Bartvelp,
interesting, we have never deal with this problem with our ESP8266. How can I reproduce this error?

Thats weird, I always have this problem. These are my build options:

Any sketch that includes the library gives me the bootloop. I used the basicConnectivty example for the the above log.

Thanks, @Bartvelp. I'm away for work, as soon as possible I will try your pull requests (this and the #180).
Do you have time to test pull request #177 and #178 on your ESP8266 (probably with this fix)?

#178 Only seems to apply to ESP32, #177 looks fine but I am unable to test atm since I only have one dw1000 currently with me

Upon some more debugging I specifcally got this error:

11:43:27.653 -> �⸮�⸮⸮=�⸮ISR not in IRAM!
11:43:27.733 -> 
11:43:27.733 -> User exception (panic/abort/assert)
11:43:27.772 -> Abort called
11:43:27.772 -> 
11:43:27.772 -> >>>stack>>>
11:43:27.812 -> 
11:43:27.812 -> ctx: cont
11:43:27.812 -> sp: 3ffffe90 end: 3fffffc0 offset: 0000
11:43:27.852 -> 3ffffe90:  feefeffe feefeffe feefeffe feefeffe  
11:43:27.893 -> 3ffffea0:  000000fe 00000000 00000000 00000000  
11:43:27.972 -> 3ffffeb0:  00000000 00000000 00000000 00ff0000  
11:43:28.023 -> 3ffffec0:  5ffffe00 5ffffe00 feefeffe 00000000  
11:43:28.062 -> 3ffffed0:  00000001 00000004 00000005 40203782  
11:43:28.102 -> 3ffffee0:  401004de 00000000 00000001 40203794  
11:43:28.183 -> 3ffffef0:  009c1001 00002af4 00000005 40203ca9  
11:43:28.223 -> 3fffff00:  00000000 3ffee698 00000005 00000004  
11:43:28.262 -> 3fffff10:  3ffe84ce 00000000 3ffee4ec 00000004  
11:43:28.344 -> 3fffff20:  3ffe84ce 3ffe84cd 00000005 40203d58  
11:43:28.388 -> 3fffff30:  00000000 0000000f 00000005 40201908  
11:43:28.434 -> 3fffff40:  00000000 feefeffe feefeffe feefeffe  
11:43:28.483 -> 3fffff50:  00002580 0000001c 00000000 3ffee638  
11:43:28.526 -> 3fffff60:  3fffdad0 00000000 3ffee518 40201069  
11:43:28.571 -> 3fffff70:  feefeffe feefeffe feefeffe feefeffe  
11:43:28.616 -> 3fffff80:  feefeffe feefeffe feefeffe feefeffe  
11:43:28.706 -> 3fffff90:  feefeffe feefeffe feefeffe 3ffee638  
11:43:28.751 -> 3fffffa0:  3fffdad0 00000000 3ffee5f8 40203388  
11:43:28.798 -> 3fffffb0:  feefeffe feefeffe 3ffe84e8 40100dfd  
11:43:28.843 -> <<<stack<<<

Hi @Bartvelp, I tried your FIX on our NodeMCU 1.0 anchors and it works well. I think it is possible to merge this PR. @0nism ?

Hey

The commit suggested by @Bartvelp solves the problem that I was referring to in the new pull request.

I tried implementing the example 'BasicConnectivityTest' on a NodeMcu 1.0, i was getting the same 'ISR not in IRAM!' error, I found out that in the new board update ie. anything later to 2.5.1 will throw this error if interrupt function is used in the esp8266. Downgrading to older version is a solution but that isn't advised as handling interrupt in the new method is fairly simple and recommended to avoid unexpected crashes.

By adding changing void interruptServiceRoutine() to void ICACHE_RAM_ATTR interruptServiceRoutine() in the DW1000Ng.cpp file, the code runs without throwing the 'ISR not in IRAM' error.

ICACHE_RAM_ATTR is basically a linker attribute which tells the esp8266 to run the function in the RAM and not in in FLASH.

@Bartvelp and @Yashvardhan001109 thanks a lot!