Jovan StosicThe ESP32 only has 520kB of RAM, a small part ~128kB is the instruction cache. It loads program code from the 4MB FLASH, then executes from this RAM. The EEPROM() library emulates the EEPROM in a AVR processor by allocating a RAM buffer of the Requested Size (multiple of 4096 bytes, because the FLASH has to ERASE 4kB at a time). It then applies your EEPROM.write() to this RAM buffer, when you commit() it Disables Cache because it has to Take control of the FLASH, (background code loading is frozen) Issues the Flash Erase command (which can take a long Time, tens to hundreds of ms). Since this task is held waiting for the Hardware, FreeRTOS finds another task that it can release, or in your case, BLE issues a callback. But, since you did not tell the compiler to always keep the callback in RAM, the Callback code is still in the FLASH which is eraseing a sector for EEPROM(). Since the background instruction loading function needs to use the cache and the FLASH to service this callback. It explodes.
Callbacks, Interrupts, any code that can execute out of order needs to always reside in the limited 128kB instructionRam. So any code that can be called out of order needs ATTR_IRAM which forces the compiler to keep it in RAM forever. AND, every call from that code must ALSO be in RAM at all times. So, be parsimonious about which code you call.
Source: https://github.com/espressif/arduino-esp32/issues/928
#/media/File:Gentile_da_fabriano,_adorazione_dei_magi.jpg){kind=link}