ESP32-C6 crashes in BLE client mode after establishing a connection whilst having the GATT table caching enabled

[csstraut]

Hi,

I am using the following ESP-AT firmware:
ESP32-C6-4MB-AT-V4.1.1.0

I tried to enable the GATT table caching from the configuration in order to speed-up the BLE connection establishment to the same peripheral.

Steps:

1. Configure the SDK as:
   CONFIG_BT_NIMBLE_GATT_CACHING=y
   CONFIG_BT_NIMBLE_GATT_CACHING_MAX_CONNS=4
   CONFIG_BT_NIMBLE_GATT_CACHING_MAX_SVCS=5
   CONFIG_BT_NIMBLE_GATT_CACHING_MAX_CHRS=32
   CONFIG_BT_NIMBLE_GATT_CACHING_MAX_DSCS=32
   CONFIG_BT_NIMBLE_GATT_CACHING_DISABLE_AUTO is not set

2. Scan for a BLE device

3. Attempt to connect to the BLE device

Results:

1. BLE connection is getting peformed, received:
   +BLECONN:0, <mac_addr>

2. A core dump is generated by the ESP32-C6 and the ESP32-C6 reboots:

Core 0 register dump:
MEPC : 0x42029936 RA : 0x42029934 SP : 0x408588e0 GP : 0x40821064
TP : 0x40858980 T0 : 0x40022494 T1 : 0xffffffe0 T2 : 0x63343930
S0/FP : 0x4085a364 S1 : 0x00000000 A0 : 0x4085a364 A1 : 0x4085a38c
A2 : 0x000222a8 A3 : 0x00000800 A4 : 0x00000000 A5 : 0x20001000
A6 : 0x00000014 A7 : 0x11c00000 S2 : 0x00000008 S3 : 0x00000000
S4 : 0x00000000 S5 : 0x00000000 S6 : 0x00000000 S7 : 0x00000000
S8 : 0x00000000 S9 : 0x00000000 S10 : 0x00000000 S11 : 0x00000000
T3 : 0x00000000 T4 : 0x000009fe T5 : 0x33356334 T6 : 0x38363336
MSTATUS : 0x00001881 MTVEC : 0x40800001 MCAUSE : 0x00000005 MTVAL : 0x00000008

Disabling the GATT caching fixes the issue.

Is there a particular configuration setting required having the GATT caching enabled?
I haven't found anything in the documentation mandating it.

[XionHsieh1025]

@csstraut

All tests are conducted based on the default configuration settings. Are these changes you made necessary?

If they are not mandatory, it is not recommended to modify the default configurations. If they are required, we will perform retests according to your adjustments.

[csstraut]

Hi @XionHsieh1025 ,
I want to speed up the connection establishment as the AT+BLECONN API returns OK only after several seconds, the reason being the fact that the ESP requests the GATT table all the time and receiving that data does take a while depending on the size of the GATT table.
As such, I wanted to use this feature to speed up things.

If there are some other configurations that might help with speeding the AT+BLECONN (ie skipping the GATT table request) or some other ways, please let me know..

[XionHsieh1025]

Doing service discovery is the default process. A pure Bluetooth connection without service discovery is practically meaningless, since all data communication relies on GATT services and characteristics.

Furthermore, normally, connection establishment, service discovery and parameter interaction can all be completed within 1 to 3 seconds.

[csstraut]

Hi @XionHsieh1025 ,
I do agree with your statement, however, I have a situation where the connect API ( AT+BLECONN) does require 7 seconds to perform and return the connect status response.
This seems to be taking that much due to the automatic GATT discovery and this varies based on the number of service/characteristic entries the BLE server has.

In my particular case the GATT table entries aren't that many on the BLE server that the ESP is connecting to, one custom service and 13 characteristics for that service, and this needs a 7 second since invoking the connection request and until actually get a status from the API. This is done in an clean RF environment with a maximum of 6 BLE devices and 1 WiFi AP.

Hence, one idea for speeding up, was to perform discovery only via the discovery APIs, rather than automatically during connection, and cache for other follow-up connections to the same BLE device.
A different one was using the already caching mechanism that the ESP does offer via CONFIG_BT_NIMBLE_GATT_CACHING.

[csstraut]

Hi @XionHsieh1025 any thoughts or supplementary feedback you might need from me related my particular case? Maybe some other ways to reduce the BLE connection establishment time that I might not be aware of or might have not touched base on?

[XionHsieh1025]

Hi @csstraut

In the current design, service discovery starts automatically as soon as a connection is established. This step is blocking: the AT command processor does not accept new commands until discovery completes.

This behavior is by design. After a BLE link is up, subsequent operations—characteristic read, write, notify, and indicate—all rely on a completed service discovery and the associated handle/parameter setup. Service discovery and related negotiation are standard post-connection procedures in BLE; separating the connection step from discovery would break that workflow.

If the connect command returned OK before discovery finished, follow-on data exchange would not be available yet, which would create an ambiguous state for users. A separate “start discovery” command would not reduce total time either: splitting one atomic sequence into two commands typically adds overhead and may increase end-to-end latency rather than shorten it.

You also mentioned CONFIG_BT_NIMBLE_GATT_CACHING. If that option behaves as documented, it should fit our existing flow without requiring application-level code changes.

Could you clarify whether the slow connection you observed happens with one specific peer device, or with all remote BLE devices?

Could you also help us understand the priority from your side: is this a must-fix requirement for your product, or mainly a performance optimization? Any change to the current connect/discovery flow would need design review, implementation, and regression testing on our side, so we would need to factor in that effort and timeline before committing to a mechanism change.

[csstraut]

Hi @XionHsieh1025 ,

Thank you for your message!

In the current design, service discovery starts automatically as soon as a connection is established. This step is blocking: the AT command processor does not accept new commands until discovery completes.

This behavior is by design. After a BLE link is up, subsequent operations—characteristic read, write, notify, and indicate—all rely on a completed service discovery and the associated handle/parameter setup. Service discovery and related negotiation are standard post-connection procedures in BLE; separating the connection step from discovery would break that workflow.

Yes, i managed to understand the design behind the scenes. Thank you for double confirm it.

You also mentioned CONFIG_BT_NIMBLE_GATT_CACHING. If that option behaves as documented, it should fit our existing flow without requiring application-level code changes.

Unfortunately turning that feature ON causes the ESP chip to crash as soon as I would attempt to establish a connection. Hence it definetely doesn't work as expected.
On top of that, even in the case it would work, I would expect BOUNDING has to be performed in order to actually benefit from the cache. Is this assumption correct?

Could you also help us understand the priority from your side: is this a must-fix requirement for your product, or mainly a performance optimization? Any change to the current connect/discovery flow would need design review, implementation, and regression testing on our side, so we would need to factor in that effort and timeline before committing to a mechanism change.

I would say a mix of both as this is intend for automating access for spaces, hence speed matters.
I would expect a BLE connection + gatt discovery in ~2 seconds rather than ~7 seconds.
The speed until the connect command returns is proportional to the size of the GATT table of the BLE device that the ESP is trying to connect to, hence me trying to find some ways to improve it.
Using a smartphone for the same thing, I can see quite a big difference in timing of the connection establishment.

[XionHsieh1025]

Hi @csstraut ,

Thank you for the follow-up, and for confirming that connection speed is important for your access-automation use case. We understand the ~2 s vs ~7 s gap is a real product requirement, not just a nice-to-have optimization.

Bonding and GATT caching
Regarding your question about bonding: bonding is not strictly required for NimBLE GATT caching to work, but it is strongly recommended in practice.

On the first connection, a full GATT service discovery is still required to populate the cache.
On subsequent connections to the same peer, the cache can be reused (if the GATT database has not changed), which is where the speed improvement comes from.
The cache is stored by peer BLE address. If the peer uses a random/resolvable address that changes between connections, cache lookup may fail unless the devices are bonded/paired.
So your assumption is partially correct: bonding is not a hard prerequisite in the stack, but it is important for reliably benefiting from the cache across reconnections.

Our reproduction attempt
We tried to reproduce the crash you reported when enabling CONFIG_BT_NIMBLE_GATT_CACHING, using the configuration you shared, but we were not able to reproduce a crash on our side.

We also noticed that, in addition to enabling CONFIG_BT_NIMBLE_GATT_CACHING, you had reduced the default GATT caching limits, for example:

CONFIG_BT_NIMBLE_GATT_CACHING_MAX_CONNS=2
CONFIG_BT_NIMBLE_GATT_CACHING_MAX_SVCS=2
CONFIG_BT_NIMBLE_GATT_CACHING_MAX_INCL_SVCS=2
CONFIG_BT_NIMBLE_GATT_CACHING_MAX_CHRS=2
CONFIG_BT_NIMBLE_GATT_CACHING_MAX_DSCS=2
We tested with these same values and still did not see a crash.

To further investigate, we intentionally set these limits even lower (all to 2) in order to force the peer GATT table to exceed the configured cache capacity. In that case, we did not get a crash either, but we did observe abnormal behavior: the AT command appeared to hang for a long time before completing.

Based on this, we suspect the issue you are seeing may be related to the GATT caching capacity limits being set too low for your peer device’s actual GATT table size, rather than a generic failure of CONFIG_BT_NIMBLE_GATT_CACHING itself. When the peer exposes more services/characteristics/descriptors than these limits allow, the stack may not behave as expected (e.g. long blocking/hanging), even if it does not always result in a hard crash.

Could you help us confirm a few things?

Peer GATT table size – How many services, characteristics, and descriptors does your target BLE device expose? (A log from nRF Connect or similar would be very helpful.)

Crash details – If you still see a crash, please share the full panic/backtrace log, your complete sdkconfig (especially all BT_NIMBLE_GATT_CACHING* options), ESP-AT/IDF version, module type, and build steps.

Timing breakdown – For a typical ~7 s connection, could you estimate how much time is spent on:

• link establishment
• MTU exchange
• GATT service discovery

First connect vs reconnect – Is the ~7 s observed on the first connection to a device, or on subsequent reconnections to the same device?

Peer addressing – Is the peer using a public or random address? Have you performed bonding/pairing?
Suggested next step on your side

As a quick test, could you try increasing the GATT caching limits to values that comfortably exceed your peer’s GATT table? For example, the NimBLE defaults are typically much higher (e.g. 64 for services/characteristics/descriptors). If the crash/hang disappears with larger limits, that would strongly support the capacity-limit theory.

We will continue investigating on our side. In parallel, we are also evaluating whether changes to the current connect/discovery flow (e.g. async discovery, partial discovery) are feasible — but those would require internal design review and regression testing, so we cannot commit to a timeline yet.

Thanks again for your patience and for the detailed feedback.

[csstraut]

Hi @XionHsieh1025 ,

Thank you for your kind feedback and looking into this.

Please find the answers to your questions bellow:

Peer GATT table size – How many services, characteristics, and descriptors does your target BLE device expose? (A log from nRF Connect or similar would be very helpful.)

The devices that I work with have different sizes, however the largest size of the GATT table some of the devices is:

• 3 primary services
• 21 characteristics (total count of characteristics from all 3 services)
• 10 descriptors

Crash details – If you still see a crash, please share the full panic/backtrace log, your complete sdkconfig (especially all BT_NIMBLE_GATT_CACHING* options), ESP-AT/IDF version, module type, and build steps.

Please find the files attached (esp_log.txt and sdkconfig)

sdkconfig.txt

Esp_log.txt

Timing breakdown – For a typical ~7 s connection, could you estimate how much time is spent on:

link establishment
MTU exchange
GATT service discovery

This are the timings for when the CONFIG_BT_NIMBLE_GATT_CACHING=n

BLE timing — 3 runs (ESP never powered off)

Clock is ms. Run 1 = cold reboot; runs 2 & 3 = warm reconnect

Phase	Run 1 (cold)	Run 2 (warm)	Run 3 (warm)
Radio link (AT+BLECONN → +BLECONN)	650 ms	776 ms	1551 ms
Post-link stall (+BLECONN → OK)	5563 ms	5612 ms	5816 ms
Link establishment total (tx → OK)	6215 ms	6388 ms	7369 ms
GATT discovery (PRIMSRV + CCHAR)	339 ms	331 ms	324 ms
↳ primary services	17 ms	17 ms	17 ms
↳ characteristics	~270 ms	~263 ms	~256 ms
MTU exchange (AT+BLECFGMTU → +BLECFGMTU:0,300)	97 ms	104 ms	59 ms

Peer addressing – Is the peer using a public or random address?

I use both public and random static advertised depending on the devices.

Have you performed bonding/pairing?

I don't have this use case, but i also can't end up doing this since the ESP crashes immediately after the device reports that the connection established

As a quick test, could you try increasing the GATT caching limits to values that comfortably exceed your peer’s GATT table? For example, the NimBLE defaults are typically much higher (e.g. 64 for services/characteristics/descriptors). If the crash/hang disappears with larger limits, that would strongly support the capacity-limit theory.

This were the values I used initally, but also with these I still had a crash (you can see the SDK config for the ESP crash log file attched)

[XionHsieh1025]

Hi @csstraut ,

Thank you again for the detailed follow-up, and for sharing the crash log, sdkconfig, timing breakdown, and peer GATT table information. That was very helpful and gave us a much clearer picture of your setup.

From what we can see so far, your GATT caching configuration does not look incorrect. In particular, with your peer table size (3 services / 21 characteristics / 10 descriptors) and the current CONFIG_BT_NIMBLE_GATT_CACHING_* limits (64), this does not appear to be a simple capacity misconfiguration.

So we would like to address the crash directly by locating the exact failing code path.

To pinpoint the source line of the Load access fault, could you help with one of the following options?

Option 1 (preferred): capture the crash under monitor

Please flash the firmware and reproduce the issue while connected with ESP-IDF monitor (or another monitor that decodes backtraces using the matching build ELF):

idf.py -p <PORT> monitor

Then run the same AT sequence that triggers the crash.
When the panic happens, the toolchain should print a decoded backtrace with file names and line numbers. Please share that full monitor output.

Option 2: send us the build artifacts for local decoding

If Option 1 is not convenient, please send:

1. The esp-at.elf from your build (usually build/esp-at.elf)
2. The full panic/crash log
3. The exact ESP-IDF commit used for that build
4. ESP-AT version (AT+GMR)

With the matching ELF and crash addresses, we can decode the fault location locally with addr2line.

Once we identify the exact crash site, we can move quickly to a root cause and a fix.

Thanks again for your patience and support.

Best regards

[csstraut]

Hi @XionHsieh1025 ,

Thank you for the help in gathering the right information.
Please check the capture of the crash under the monitor attached

ESP_Crash_logs.txt

[XionHsieh1025]

Hi @csstraut

This crash doesn’t look related to the config change. Could you check whether it still reproduces if that config is left unchanged?

Also, what is the peer device? If I use an ESP chip to emulate the peer with the same service list, would that be enough to reproduce the issue?

If I can reproduce it locally, it should be much more efficient to debug and fix.

[csstraut]

Hi @XionHsieh1025 ,

This crash doesn’t look related to the config change. Could you check whether it still reproduces if that config is left unchanged?

In order to reproduce the crash, the only change that I did was to enabled the GATT caching. CONFIG_BT_NIMBLE_GATT_CACHING=y
Other than that, I haven't changed anything else.

If I disable the GATT caching feature, the ESP doesn't crash anymore.

Also, what is the peer device?

Some nordic and cypress chips.

If I use an ESP chip to emulate the peer with the same service list, would that be enough to reproduce the issue?

I would expect that it might.

[XionHsieh1025]

Hi @csstraut

Thanks for the clarification.

To help us reproduce the issue on our side, could you please connect to the peer device (Nordic/Cypress) with a third-party BLE app on your phone (e.g. nRF Connect / LightBlue), and send us a screenshot of the full GATT service/characteristic list?

We’ll then try to emulate the same service layout on an ESP device and attempt to reproduce the crash with GATT caching enabled.