Using ble_spp_server_demo as starting point. I added some code and I have a problem with interrupts when I call esp_ble_gatts_app_register(ESP_SPP_APP_ID).
E.g. interrupt gpio_edge_isr sometimes doesn’t fire. I have clock with 100us period connected to port and isr for positive edge. It doesn’t occure sometimes. It skips 2 interrupt events and third event service is shifted. It repeats for about 45ms.
Do You know, where it can stuck ? Changing my ISR to LEVEL3 doesn’t help.
I don’t see that ble use interrupts so what prevents my interrupt LEVEL3 from executing?
Problem does not occure when i comment line:
//esp_ble_gatts_app_register(ESP_SPP_APP_ID);
but bluetooth doesn’t work… so it is not good workaround 
The problem description contains not much context…
But are you sure or did you ensure/measure that your interrupt handling is fast enough to cope with the desired interrupt (1/100us) rate and also that your system (including all your other interrupt sources) is able to do so ? And what is LEVEL3 ?
Yes, I measured that handling is fast (set port on the beginning ISR and clear od the end) - see short pulses on oscilloscope.
I have only one interrupt that i know. I’m not sure that BLE use also interrupt but didn’t found in code.
LEVEL3 is interrupt priority (higher level - higher priority).
Strange … if your ISR is fast enough and you don‘t have critical sections in your or 3rd party code disabling interrupts too long, there is no reason why you miss interrupts 
I guess you verified it using e.g. an IRQ counter or something that you miss some of the events. Assuming the IRQ has the highest prio in your application and your MCU (which one ?) supports nested interrupts.
I tried to disabling interrupts by
ESP_INTR_DISABLE(n);//n=0…31
and see that if i disable interrupt no 7, the problem stops (also ble doesn’t work) so this is interrupt that makes problem.
Than check what is the number of my interrupt (that corrupted by int no. 7) also by disabling interrupts one-by-one and see that my interrupt is no. 23.
Now i checked what are the priorities of interrupt 7 and 23. I used:
ESP_LOGI(TAG, “Interrupt 7 level = %d\n”, interrupt_controller_hal_desc_level(7));
and
ESP_LOGI(TAG, “Interrupt 23 level = %d\n”, interrupt_controller_hal_desc_level(23));
And have:
I (1290) main: Interrupt 7 level = 1
I (1290) main: Interrupt 23 level = 3
so why higher interrupt (level3) does not interrupt the lower interrupt (level1) ?
It should, right?
Hmmm… how can i check if it is there?
What is interrupt 7 doing? Does it re-enable interrupts if that is necessary on an ESP? How long does it take to execute? Does it disable interrupts? Are you sure you can nest interrupts?
I don’t know what is interrupt 7. I didn’t find any information about interrupt number identyfication in docummentation, but it is used by ble (if I comment ble initialisation, problem doesn’t occure).
I think that it re-enable because, interrupts works all the time.
I don’t know exactly how long it executes because i can’t identify where this interrupt is serviced. It can be c.a. 200…300 us because that is the time where my gpio edge interrupt is missed. This interrupt period is c.a. 45ms.
I found what is interrupt 7. This is interrupt cpu using table from soc.h file:
/*************************************************************************************************************
* Intr num Level Type PRO CPU usage APP CPU uasge
* 0 1 extern level WMAC Reserved
* 1 1 extern level BT/BLE Host HCI DMA BT/BLE Host HCI DMA
* 2 1 extern level
* 3 1 extern level
* 4 1 extern level WBB
* 5 1 extern level BT/BLE Controller BT/BLE Controller
* 6 1 timer FreeRTOS Tick(L1) FreeRTOS Tick(L1)
* 7 1 software BT/BLE VHCI BT/BLE VHCI
* 8 1 extern level BT/BLE BB(RX/TX) BT/BLE BB(RX/TX)
* 9 1 extern level
* 10 1 extern edge
* 11 3 profiling
* 12 1 extern level
* 13 1 extern level
* 14 7 nmi Reserved Reserved
* 15 3 timer FreeRTOS Tick(L3) FreeRTOS Tick(L3)
* 16 5 timer
* 17 1 extern level
* 18 1 extern level
* 19 2 extern level
* 20 2 extern level
* 21 2 extern level
* 22 3 extern edge
* 23 3 extern level
* 24 4 extern level TG1_WDT
* 25 4 extern level CACHEERR
* 26 5 extern level
* 27 3 extern level Reserved Reserved
* 28 4 extern edge DPORT ACCESS DPORT ACCESS
* 29 3 software Reserved Reserved
* 30 4 extern edge Reserved Reserved
* 31 5 extern level
*************************************************************************************************************
*/
Ther is also in this file:
#define ETS_RWBLE_INTR_SOURCE 7/**< interrupt of RWBLE, level*/
#define ETS_GPIO_NMI_SOURCE 23/**< interrupt of GPIO, NMI*/
So, it is BLE VHCI interrupt and has level 1. My interrupt 23 has level 3. So the only reason why higher priority interrupt is corrupted by lower priority interrupt, is that nesting is not implemented?
I see that nested interrupts are implemented, because of:
#define configKERNEL_INTERRUPT_PRIORITY 1
and
#define configMAX_SYSCALL_INTERRUPT_PRIORITY XCHAL_EXCM_LEVEL
and
#define XCHAL_EXCM_LEVEL 3 /* level masked by PS.EXCM */
Right?
Is it sure that level 3 interrupt should break level 1 interrupt if nesting is implemented?
Can somebody help to analise “ble_spp_server_demo” project? Where is ISR code for BLE VHCI ? And what does it mean that it is software type of interrupt?