ASSERT_WARN(1 8), in lc_task.c in serial output when using ESP32 Bluetooth Classic in Master Mode

[alastaira]

Board

ESP32 DevKit v1 (ESP-WROOM-32)

Device Description

ESP DevKit v1

Hardware Configuration

No other hardware connected

Version

v1.0.6

IDE Name

Arduino IDE 1.8.15

Operating System

Windows 10

Flash frequency

80MHz

PSRAM enabled

no

Upload speed

921600

Description

Using Bluetooth Classic in Master mode on the ESP32 to connect to an HC-06 slave that is transmitting data.
The ESP32 pairs successfully to the device, including the required Bluetooth pairing PIN code, and data is received correctly.

However, when printing the received data to the serial output of the ESP32, an additional message is periodically printed in the output (every few seconds) - "ASSERT_WARN(1 8), in lc_task.c at line 1394", as shown below:

I think this error is possibly related to the issues described at:

• bt spp connection shift system time (IDFGH-3121) esp-idf#5140
• >ASSERT_WARN(1 8), in lc_task.c at line 5054ASSERT_WARN(1 8), in lc_task.c at line 5054 PowerBroker2/ELMduino#43
  Those reference different line numbers (but also relate to earlier versions of the ESP32 codebase), but otherwise describe similar scenarios related to Bluetooth connections. However, neither issue referenced has been closed with a solution.

Sketch

#include "BluetoothSerial.h"

uint8_t address[6] = {0x98, 0xDA, 0x20, 0x03, 0xA5, 0x24};
char *pin = "1234";

BluetoothSerial SerialBT;

void setup() {
  Serial.begin(115200);
  SerialBT.begin("ESP32", true);
  SerialBT.setPin(pin);
  SerialBT.connect(address);
}

void loop() {
  if(SerialBT.available()) {  
    Serial.print(SerialBT.read());
  }
}

Debug Message

12365485848585748584812536123665156584549495845534858574812536123654858485857485848125361236651565845494958455348585748125361236548584858574858481253612366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536123654858485857485848125361236651565845494958455348585748125361236548584858574858481253612366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536
ASSERT_WARN(1 8), in lc_task.c at line 1394
1236548584858574858481253612366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536123654858485857485848125361236651565845494958455348585748125361236548584858574858481253612366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536123654858485857485848125361236651565845494958455348585748125361236548584858574858481253612366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536123654858485857485848125361236651565845494958455348585748125361236548584858574858481253612366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536123654858485857485848125361236651565845494958455348585748125361236548584858574858481253612366515658454949584553485857481253612365485848585748584812536
ASSERT_WARN(1 8), in lc_task.c at line 1394
12366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536123654858485857485848125361236651565845494958455348585748125361236548584858574858481253612366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536123654858485857485848125361236651565845494958455348585748125361236548584858574858481253612366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536123654858485857485848125361236651565845494958455348585748125361236548584858574858481253612366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536123654858485857485848125361236651565845494958455348585748125361236548584858574858481253612366515658454949584553485857481253612365485848585748584812536123665156584549495845534858574812536
ASSERT_WARN(1 8), in lc_task.c at line 1394

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[zvikaf]

Got the same error, But to my surprise it happens only if i connect to an HC-06 that is connected to arduino nano.
connecting the HC-06 with FTDI to the USB stops the error ...
Nothing was changed in the ESP32 program.
Did some checks, disconnected the TX RX lines at the HC-06.. had still errors..
moved the dongle closer to the ESP .. and all is gone, suspect either power problem or noisy reception :-)
and now it's back ... have no idea what was changed

[alastaira]

Curious. In my case, the HC-06 is connected to an STM32F103 chip, but I've no reason to think there's any issue with the power supply.

[zvikaf]

my HC-06 connects to NANO, tried two HC-06 boards, tried also with external 5V supply, made no difference.
This error is only up when the ESP32 is connected on SPP... anyway is has no affect on my code as I do not use the serial (just for debug) and the OLED screen used, works fine, also checked range and found no effect (yet) :-)

[magicmicros]

Same problem here, communicating with an ANT BMS (not sure that module is on that).
Usually get the ASSERT shortly after a 140 byte block have been received, but sometimes it occurs in the middle of the block.

[VojtechBartoska]

Hello, can you please retest this on v2.0.3-rc1?

[magicmicros]

Sadly, still the same.
My error message is "ASSERT_WARN(1 8), in lc_task.c at line 1409".
I'm connecting to an ANT BMS, using SPP.
Simple comms, sending 6 bytes, receiving 140 bytes, repeated every second.
The ASSERT doesn't always show up, but comes every 4-5 blocks or so.

[magicmicros]

Maybe I should add that I'm on an old WROOM module.
Chip is ESP32-D0WD (revision 1)

[VojtechBartoska]

Ok, thanks for testing. I'm adding this to our Roadmap and we will test it. :)

[ricardoquesada]

@VojtechBartoska could you add more details regarding why it is showing the Warn?

I'm triggering it using pure ESP-IDF v4.4.1 with BT classic and some tasks... but the file lc_task.c is not part of esp-idf... and I'd like to know why the Warn is being triggered so that I can fix it in my code. Thanks!

[lbernstone]

There are compiled binaries used in the bluetooth stack. lc_task.c is likely a part of that proprietary blob, so you cannot see that code.

[ricardoquesada]

@lbernstone yep... that's why I was requesting further info... like why are we seeing that message.

I further debugged my application, thinking that it was related to the task I was creating, but apparently just a simple connection from my BR/EDR mouse triggers it. It happens even if I don't start my tasks / timers.

In case it helps, this is the mouse that I'm using it: Bluetooth Wireless Mouse, TECKNET 3
https://www.amazon.com/dp/B082V7PWD1?psc=1&ref=ppx_yo2ov_dt_b_product_details

My guess is that the mouse is using HC-06 internally... but I haven't dissasembled it yet.

[ricardoquesada]

I tested with another mouse, same issue. It seems that both mice are using the same chip, which is a BK3632

http://www.bekencorp.com/en/goods/detail/cid/18.html

And seems a popular choice in mice that supports both BR/EDR and BLE and propietary 2.4Ghz

[alastaira]

There are compiled binaries used in the bluetooth stack. lc_task.c is likely a part of that proprietary blob, so you cannot see that code.

Indeed. And as such there's not much the majority of us can do other than to report these issues with as much detail as possible, and hope that a fix is developed!

[ricardoquesada]

To raise awareness of how popular the BK3632 chip is: mice advertised as "triple mode bt3.0 / bt5.0 / 2.4Ghz" are using most probably a BK3632... meaning that we cannot use them to connect to an ESP32.

I purchased 3 mice "triple mode", all of them failed with the ASSERT_WARN()... all of them using BK3632.

For context, see my previous comment: #6193 (comment)

[fumanchi]

Sadly, still the same. My error message is "ASSERT_WARN(1 8), in lc_task.c at line 1409". I'm connecting to an ANT BMS, using SPP. Simple comms, sending 6 bytes, receiving 140 bytes, repeated every second. The ASSERT doesn't always show up, but comes every 4-5 blocks or so.

I am communicating with the "Ant BMS 16S 100A" and have the same warnings on my ESP32 WROOM (38 pin developer board). Have you made any progress regarding this annoying issue? Have you succeeded in reliably triggering the bluetooth interface of the BMS by simply switching a digital output connected to the bms trigger wires (and ground)?

[RMM-R]

Sadly, still the same. My error message is "ASSERT_WARN(1 8), in lc_task.c at line 1409". I'm connecting to an ANT BMS, using SPP. Simple comms, sending 6 bytes, receiving 140 bytes, repeated every second. The ASSERT doesn't always show up, but comes every 4-5 blocks or so.

I am communicating with the "Ant BMS 16S 100A" and have the same warnings on my ESP32 WROOM (38 pin developer board). Have you made any progress regarding this annoying issue? Have you succeeded in reliably triggering the bluetooth interface of the BMS by simply switching a digital output connected to the bms trigger wires (and ground)?

Did you manage to connect to ant bms ? I'm trying to solve the same problem, but my connection is not established every time. After the connection is lost, you need to connect to the bms by phone, and only then it is possible to establish a connection with esp32 again. Can you show your connection code with ant bms ?

[fumanchi]

Sadly, still the same. My error message is "ASSERT_WARN(1 8), in lc_task.c at line 1409". I'm connecting to an ANT BMS, using SPP. Simple comms, sending 6 bytes, receiving 140 bytes, repeated every second. The ASSERT doesn't always show up, but comes every 4-5 blocks or so.

I am communicating with the "Ant BMS 16S 100A" and have the same warnings on my ESP32 WROOM (38 pin developer board). Have you made any progress regarding this annoying issue? Have you succeeded in reliably triggering the bluetooth interface of the BMS by simply switching a digital output connected to the bms trigger wires (and ground)?

Did you manage to connect to ant bms ? I'm trying to solve the same problem, but my connection is not established every time. After the connection is lost, you need to connect to the bms by phone, and only then it is possible to establish a connection with esp32 again. Can you show your connection code with ant bms ?

Connecting to the BMS works flawless and besides the assert warnings I have no problems communicating.

setup:

SerialBT.begin(name, true);
SerialBT.setPin(pin);

loop:

if(SerialBT.connected())
  {
    uint8_t test[] {0xDB, 0xDB, 0x00, 0x00, 0x00, 0x00};
    for (int i = 0; i < 6; ++i)
      SerialBT.write(test[i]);
    
    uint8_t buffer[140];
    if (SerialBT.readBytes(buffer, 140) == 140)
    {
      uint8_t header[] {0xAA, 0x55, 0xAA, 0xFF};
      if (memcmp(header, buffer, 4) == 0)
      {
        // checksum
        int16_t checksum = 0;
        for (int i = 4; i < 138; ++i)
          checksum += buffer[i];

        Serial.printf("CRC^Calculated: %d\n", checksum);
        Serial.printf("CRC^Given: %d\n", (buffer[138] << 8) + buffer[139]);

        Serial.printf("V^Total: %f V\n", ((float)((buffer[4] << 8) + buffer[5])) * 0.1);
        for (int i = 0; i < 15; ++i)
          Serial.printf("V^%d: %f V\n", i + 1, ((float)((buffer[6+i*2] << 8) + buffer[7+i*2])) * 0.001);
        Serial.printf("Current: %f A\n", ((float)(((((buffer[70] << 8) + buffer[71]) << 8) + buffer[72]) << 8) + buffer[73]) * 0.1);
        Serial.printf("SoC: %d %\n", buffer[74]);
        Serial.printf("Capacity^Total: %f Ah\n", ((float)(((((buffer[75] << 8) + buffer[76]) << 8) + buffer[77]) << 8) + buffer[78]) * 0.000001);
        Serial.printf("Capacity^Remaining: %f Ah\n", ((float)(((((buffer[79] << 8) + buffer[80]) << 8) + buffer[81]) << 8) + buffer[82]) * 0.000001);
        Serial.printf("Capacity^Cycle: %f Ah\n", ((float)(((((buffer[83] << 8) + buffer[84]) << 8) + buffer[85]) << 8) + buffer[86]) * 0.001);
        Serial.printf("Uptime: %d s\n", (((((buffer[87] << 8) + buffer[88]) << 8) + buffer[89]) << 8) + buffer[90]);

        Serial.printf("Charging: %d\n", buffer[103]);
        Serial.printf("Discharging: %d\n", buffer[104]);
        Serial.printf("Balancing: %d\n", buffer[105]);

        Serial.printf("Tire length: %d mm\n", (buffer[106] << 8) + buffer[107]);
        Serial.printf("#Pulses: %d/week\n", (buffer[108] << 8) + buffer[109]);

        Serial.printf("Relay: %d\n", buffer[110]);

        Serial.printf("Current Power: %d W\n", (((((buffer[111] << 8) + buffer[112]) << 8) + buffer[113]) << 8) + buffer[114]);
    
        Serial.printf("Cell^Highest: %d\n", buffer[115]);
        Serial.printf("Voltage^Max: %f\n", ((float)(buffer[116] << 8) + buffer[117]) * 0.001);
        Serial.printf("Cell^Lowest: %d\n", buffer[118]);
        Serial.printf("Voltage^Min: %f\n", ((float)(buffer[119] << 8) + buffer[120]) * 0.001);
        Serial.printf("Voltage^Avg: %f\n", ((float)(buffer[121] << 8) + buffer[122]) * 0.001);
        Serial.printf("#Cells: %d\n", buffer[123]);
      }
    }

[RMM-R]

I have almost the same code. But the first connection to the BMS goes flawlessly, and if the controller is reset, it does not reconnect again. If you change the MAC address of the ESP32, it connects again without any problems. That is, in order for it to work, I have to connect with a different MAC address every time.

[fumanchi]

I have almost the same code. But the first connection to the BMS goes flawlessly, and if the controller is reset, it does not reconnect again. If you change the MAC address of the ESP32, it connects again without any problems. That is, in order for it to work, I have to connect with a different MAC address every time.

This does not happen here... I can always connect/reconnect without any hassle...

[VojtechBartoska]

Hi @alastaira, is this issue still valid on latest version 2.0.14? (based on ESP-IDF v4.4)

[BlackWolfDEsign]

Hi @alastaira, is this issue still valid on latest version 2.0.14? (based on ESP-IDF v4.4)

SerialBT.begin(String(DEVICE_NAME), false);
esp_bredr_tx_power_set(ESP_PWR_LVL_N0, ESP_PWR_LVL_P3);

and i get: ASSERT_WARN(110 36), in lc_task.c at line 2300

[AVTAR0901]

Same problem here, communicating with an ANT BMS (not sure that module is on that). Usually get the ASSERT shortly after a 140 byte block have been received, but sometimes it occurs in the middle of the block.

hey Im also trying ti connect to ANT BMS, I m using default code serial tp serial BTM(Arduino Library), im getting same issue, is yours solved??

if not please let me know

[Parsaabasi]

Hello,

I close this since this report contains the release we no longer support. Please try the new versions and in case the issue persists, feel free to reopen it.

Thanks