Hi all,
I am wondering if you could give me some hints on where to look.
I am sending packages of around 100 bytes from a set of sensors, and sending them in batches.
Most of the time, the ESP32 reboots with an exception.
If I place a "delay" of 100ms between indications, it runs for long periods.
My guess is some some resources is being exausted, probably RAM.
How do I check that:
esp_err_t rc = esp_ble_gatts_send_indicate(gl_test.gatt_if, gl_test.conn_id, gl_test.char_handle, n, buf, false );
I am checking the error code, it seems to be ok.
Rosimildo
BLE Indication crashes
Re: BLE Indication crashes
Hi there,
Since I did not get any answer, I've decided to go deep on this.
The issues were with the BT stack.
Below are the fixes. I don't know if that is the best way... My expectations were right, and the memory allocator was not checking for errors....
Thanks!
The diff is bellow.
diff --git a/components/bt/bluedroid/btc/core/btc_task.c b/components/bt/bluedroid/btc/core/btc_task.c
index a245f54..9c58955 100644
--- a/components/bt/bluedroid/btc/core/btc_task.c
+++ b/components/bt/bluedroid/btc/core/btc_task.c
@@ -101,7 +101,7 @@ bt_status_t btc_transfer_context(btc_msg_t *msg, void *arg, int arg_len, btc_arg
memcpy(&lmsg, msg, sizeof(btc_msg_t));
if (arg) {
lmsg.arg = (void *)GKI_getbuf(arg_len);
- memset(lmsg.arg, 0x00, arg_len); //important, avoid arg which have no length
+ //memset(lmsg.arg, 0x00, arg_len); //important, avoid arg which have no length
if (lmsg.arg == NULL) {
return BT_STATUS_NOMEM;
}
diff --git a/components/bt/bluedroid/gki/gki_buffer.c b/components/bt/bluedroid/gki/gki_buffer.c
index 201df90..981530b 100644
--- a/components/bt/bluedroid/gki/gki_buffer.c
+++ b/components/bt/bluedroid/gki/gki_buffer.c
@@ -181,6 +181,7 @@ void GKI_init_q (BUFFER_Q *p_q)
void *GKI_getbuf_func(UINT16 size)
{
BUFFER_HDR_T *header = osi_malloc(size + BUFFER_HDR_SIZE);
+ if( !header ) return NULL;
header->status = BUF_STATUS_UNLINKED;
header->p_next = NULL;
header->Type = 0;
diff --git a/components/esp32/lib b/components/esp32/lib
index 1627461..45414a6 160000
--- a/components/esp32/lib
+++ b/components/esp32/lib
@@ -1 +1 @@
-Subproject commit 1627461bf2fc2ec8a090b30cddae2118d542c454
+Subproject commit 45414a6778e1bf2855f18a8c6b954d5cf575bb40
Since I did not get any answer, I've decided to go deep on this.
The issues were with the BT stack.
Below are the fixes. I don't know if that is the best way... My expectations were right, and the memory allocator was not checking for errors....
Thanks!
The diff is bellow.
diff --git a/components/bt/bluedroid/btc/core/btc_task.c b/components/bt/bluedroid/btc/core/btc_task.c
index a245f54..9c58955 100644
--- a/components/bt/bluedroid/btc/core/btc_task.c
+++ b/components/bt/bluedroid/btc/core/btc_task.c
@@ -101,7 +101,7 @@ bt_status_t btc_transfer_context(btc_msg_t *msg, void *arg, int arg_len, btc_arg
memcpy(&lmsg, msg, sizeof(btc_msg_t));
if (arg) {
lmsg.arg = (void *)GKI_getbuf(arg_len);
- memset(lmsg.arg, 0x00, arg_len); //important, avoid arg which have no length
+ //memset(lmsg.arg, 0x00, arg_len); //important, avoid arg which have no length
if (lmsg.arg == NULL) {
return BT_STATUS_NOMEM;
}
diff --git a/components/bt/bluedroid/gki/gki_buffer.c b/components/bt/bluedroid/gki/gki_buffer.c
index 201df90..981530b 100644
--- a/components/bt/bluedroid/gki/gki_buffer.c
+++ b/components/bt/bluedroid/gki/gki_buffer.c
@@ -181,6 +181,7 @@ void GKI_init_q (BUFFER_Q *p_q)
void *GKI_getbuf_func(UINT16 size)
{
BUFFER_HDR_T *header = osi_malloc(size + BUFFER_HDR_SIZE);
+ if( !header ) return NULL;
header->status = BUF_STATUS_UNLINKED;
header->p_next = NULL;
header->Type = 0;
diff --git a/components/esp32/lib b/components/esp32/lib
index 1627461..45414a6 160000
--- a/components/esp32/lib
+++ b/components/esp32/lib
@@ -1 +1 @@
-Subproject commit 1627461bf2fc2ec8a090b30cddae2118d542c454
+Subproject commit 45414a6778e1bf2855f18a8c6b954d5cf575bb40
Re: BLE Indication crashes
Yakes!, this still don't solve it!
It resolve the exception, but the code silently fails, since the "deep_copy" callbacks can't return errors, even though they might fail due to lack of resources ( memory ), they log errors, but the caller can't see the silent error and return "OK" to parent, even though the command failed.
This will requires a somewhat big re-factoring.
Yakes!, back to the delay... so now... not enough energy to fix all this.
Rosimildo
It resolve the exception, but the code silently fails, since the "deep_copy" callbacks can't return errors, even though they might fail due to lack of resources ( memory ), they log errors, but the caller can't see the silent error and return "OK" to parent, even though the command failed.
This will requires a somewhat big re-factoring.
Yakes!, back to the delay... so now... not enough energy to fix all this.
Rosimildo
Who is online
Users browsing this forum: No registered users and 99 guests