LoadProhibited error in r_rw_schedule

[slivingston]

We are experiencing frequent but intermittent crashes after the first few seconds of our board initialization. We are successfully initializing wifi and ble, connecting to a remote wifi AP, and 3 ble peripherals. However, we are occasionally seeing the following exception:

Code: Select all

Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x40047de7  PS      : 0x00060230  A0      : 0x80049b9c  A1      : 0x3ffe3240  
A2      : 0x07ffffff  A3      : 0x0000001a  A4      : 0x00001bc0  A5      : 0x00000001  
A6      : 0x3ffe32a0  A7      : 0x00000000  A8      : 0x3ffbd520  A9      : 0x3ffe3220  
A10     : 0x0030bb00  A11     : 0x00000001  A12     : 0x00000000  A13     : 0x3ffafd68  
A14     : 0x00000000  A15     : 0x3ffb8360  SAR     : 0x00000016  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000008  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0x00000000  

Backtrace: 0x40047de7:0x3ffe3240 0x40049b99:0x3ffe32a0 0x400457cd:0x3ffe32d0 0x4001a637:0x3ffe3310 0x40019d11:0x3ffe3340 0x40055b4d:0x3ffe3360 0x4015dabf:0x3ffe3380 0x4015db0f:0x3ffe33a0
0x4015dabf: r_rw_schedule at ??:?

0x4015db0f: btdm_controller_task at ??:?


CPU halted.

The backtrace seems suspect to me after r_rw_schedule, as though it jumps to an erroneous address. This is only occurring occasionally after a board reset, and more frequently if we have just done a "make flash monitor" which forces two rapid succession resets.

I also do not know if it is coincidence, but it seems to follow soon after a successful ESP_GAP_BLE_UPDATE_CONN_PARAMS_EVT.

I enabled some tracing at the bt level and this sequence is happening right before the cited exception:

Code: Select all

I (6229) ble_ctrl: ESP_GAP_BLE_UPDATE_CONN_PARAMS_EVT Success - 00:0b:57:2e:57:13 int=6, min=6, max=10, lat=0, timeout=400
E (6251) BT: gatt_get_ch_state: ch_state=4
E (6251) BT: gatt_process_notification 
E (6251) BT: gatt_get_link_encrypt_status status=0x8e
E (6251) BT: gatt_cl_op_cmpl_cback
E (6251) BT: gap_ble_c_cmpl_cback() - op_code: 0x06  status: 0x8e  read_type: 0x8fc3

E (6252) BT: GATT_GetConnectionInfor conn_id=259
E (6252) BT: GATT_GetConnectionInfor conn_id=260
E (6256) BT: gatt_get_ch_state: ch_state=4
E (6256) BT: gatt_process_error_rsp 
E (6256) BT: gatt_proc_disc_error_rsp reason: 0a cmd_code 0008
E (6256) BT: Discovery completed
E (6256) BT: gatt_end_operation status=0 op=1 subtype=3
E (6257) BT: GATTC_Discover conn_id=516 disc_type=4
E (6286) BT: gatt_get_ch_state: ch_state=4

I have seen on github references to this type of exception, but all of the issues have been closed. We are using the very latest esp-idf cloned today, commit 80eb3b6. And we had seen the issue prior to this update.

Has anyone seen this recently and/or could offer any advice?

[ESP_Tianhao]

Hi, slivingston,
Could you provide your elf file? It could help me debug it. Thanks.