Illegal instruction (IllegalInstruction) calling ble_gattc_disc_all_svcs() (IDFGH-12747)

[nicklasb]

Answers checklist.

• [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [x] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

ESP-IDF 5.2.1

Espressif SoC revision.

Esptool does not work on MacOS, or is it?

Operating System used.

macOS

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32 LoRa32 v1

Power Supply used.

USB

What is the expected behavior?

When calling ble_gattc_disc_all_svcs() i expect services to be discovered and the callback be called.

What is the actual behavior?

Instead the callback is not called, but an illegal instruction error is raised. See debug log.

Steps to reproduce.

1. Use a Lora32 v1
2. Initialize BLE both as a client and server
3. Se above illegal instruction

Debug Logs.

I (2781) NimBLE: GATT procedure initiated: discover all services

Guru Meditation Error: Core  0 panic'ed (IllegalInstruction). Exception was unhandled.

Core  0 register dump:
PC      : 0x4073cf2c  PS      : 0x00060830  A0      : 0x800fd1be  A1      : 0x3ffd11b0  
A2      : 0x3ffd120c  A3      : 0x400d7cd8  A4      : 0x00000000  A5      : 0x3ffc4a00  
A6      : 0x3f400b80  A7      : 0x00000006  A8      : 0x8073cf2c  A9      : 0x3ffd10c0  
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x3ffd1090  A13     : 0x3ffd1798  
A14     : 0x03000019  A15     : 0x03000015  SAR     : 0x0000000a  EXCCAUSE: 0x00000000  
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  


Backtrace: 0x4073cf29:0x3ffd11b0 |<-CORRUPTED

  #0  0x4073cf29:0x3ffd11b0 in ?? ??:0

More Information.

This might be related to the fact that I am both being a client scanning and a server advertising. However, I am not having this problem on my T-beam SIM 7000G board, which is the one the failing LoRa32 v1 is communicating with. As far as I can see, the connection handle is 0 (which is expected, and hints that it is the first connection). And the callback does nothing before me having debug logging.

[rahult-github]

Hi @nicklasb ,

Can you please help share your application changes done OR any minimal example based on IDF that we can use to replicate the issue at our end ?

Also, can you please help share your .elf file for the run when the above crash was observed ?

[nicklasb]

Hi @nicklasb ,

Can you please help share your application changes done OR any minimal example based on IDF that we can use to replicate the issue at our end ?

Also, can you please help share your .elf file for the run when the above crash was observed ?

Hi, the problem is that this is a part of a large implementation, I don't quite know where to begin to end up there TBH. I hoped that there someone with insight in the source could consider the different boards. I'll go back to this in a while after using other boards a short while and see if I accidentally fix it while developing for them.

[rahult-github]

Hi @nicklasb , did you get to reproduce issue again and have any further information for this ?

[rahult-github]

Closing this issue. Please feel free to reopen in case of further updates.