espressif / arduino-esp32

Arduino core for the ESP32
GNU Lesser General Public License v2.1
13.28k stars 7.35k forks source link

BT Serial freezes the Esp32 #3922

Closed Risineo closed 4 years ago

Risineo commented 4 years ago

Hardware:

Board: lolin32 Core Installation 1.0.4 (PlatformIO calls it 1.12.0 , I assume it is 1.0.4) IDE name: PlatformIO inside VSCode, running the arduino-esp32 core Flash Frequency: 40Mhz PSRAM enabled: no Upload Speed: 115200 Computer OS: Windows 10

Description:

If the receiving module loses connection in the exact moment that the tranmitting module is trying to send data to it, the transmitting module will become unresponsive. The reason for the loss of connection seems to be of no importance (loss of power, reset, brown-out, etc.) In all instances the module has to be reset for it to reassume operation.

Sketch:

Both the master and slave side are basically copies of the SerialtoSerialBT examples. https://github.com/espressif/arduino-esp32/tree/idf-release/v4.0/libraries/BluetoothSerial/examples Only the master side is modified so it sends the 6 byte array in rapid succession.

//This example code is in the Public Domain (or CC0 licensed, at your option.)
//By Victor Tchistiak - 2019
//
//This example demostrates master mode bluetooth connection and pin 
//it creates a bridge between Serial and Classical Bluetooth (SPP)
//this is an extention of the SerialToSerialBT example by Evandro Copercini - 2018
//

#include "BluetoothSerial.h"

BluetoothSerial SerialBT;

String MACadd = "AA:BB:CC:11:22:33";
uint8_t address[6]  = {0xAA, 0xBB, 0xCC, 0x11, 0x22, 0x33};
//uint8_t address[6]  = {0x00, 0x1D, 0xA5, 0x02, 0xC3, 0x22};
String name = "OBDII";
const char *pin = "1234"; //<- standard pin would be provided by default
bool connected;
int8_t irDataArray[6] = (0x11, 0x22 ,0x33, 0x44, 0x55, 0x66);

void setup() {
  Serial.begin(115200);
  //SerialBT.setPin(pin);
  SerialBT.begin("ESP32test", true); 
  //SerialBT.setPin(pin);
  Serial.println("The device started in master mode, make sure remote BT device is on!");

  // connect(address) is fast (upto 10 secs max), connect(name) is slow (upto 30 secs max) as it needs
  // to resolve name to address first, but it allows to connect to different devices with the same name.
  // Set CoreDebugLevel to Info to view devices bluetooth address and device names
  connected = SerialBT.connect(name);
  //connected = SerialBT.connect(address);

  if(connected) {
    Serial.println("Connected Succesfully!");
  } else {
    while(!SerialBT.connected(10000)) {
      Serial.println("Failed to connect. Make sure remote device is available and in range, then restart app."); 
    }
  }
  // disconnect() may take upto 10 secs max
  if (SerialBT.disconnect()) {
    Serial.println("Disconnected Succesfully!");
  }
  // this would reconnect to the name(will use address, if resolved) or address used with connect(name/address).
  SerialBT.connect();
}

void loop() 
{
   SerialBT.write(irDataArray, 6);
   delay(20);
   SerialBT.write(irDataArray, 6);
   delay(20);
   SerialBT.write(irDataArray, 6);
   delay(1000);
}

Debug Messages:

debug_level=5 reveals:

[V][BluetoothSerial.cpp:269] esp_spp_cb(): ESP_SPP_CONG_EVT: CONGESTED
[V][BluetoothSerial.cpp:277] esp_spp_cb(): ESP_SPP_WRITE_EVT: 1 CONGESTED

and a couple of seconds later:

[I][BluetoothSerial.cpp:250] esp_spp_cb(): ESP_SPP_CLOSE_EVT

After that I have not been able to execute any further code.

I have also tried to implement checks on whether there is actually an active connection to the other side just before a message is transmitted, however all the functions the library offers, seem to be too unresponsive to allow for rapid data tranmission. I plan to set up one board to receive IR data in possibly rapid succession and to have it transmit that data to a second esp32 so it can execute commands and possibly send commands back to the first board that is equipped with the IR receivers.

If someone can offer advice on how I can successfully set up watchdogs to prevent the code from sending data when there is no connection, I would be most grateful aswell. Loss of some packages would be a minor problem, but having the entire mcu freeze up is of no use of course.

patfelst commented 4 years ago

I'm getting a similar thing when attempting to connect to a bluetooth classic OBD2 dongle.

Using platform IO: espressif32; board: esp32dev; framework: arduino. Have tried three different ESP32 boards. A Espressif Devkit C V4, a Tinypico and a DOIT Devkit v1. All show the same behaviour. Powering the boards from a Mac laptop over USB, also tried different USB cables and also tried from a USB power supply with no luck.

I get a guru meditation unhandled exception SW_CPU_RESET when the execution reaches bool connected = SerialBT.connect(address);. The complete code is here https://pastebin.com/S0em3wnD, the crash occurs at line 61.

Part of the code is executing as the LEDs on the OBD2 dongle flash (the host and the OBD LED).

Here's a screen grab of the crash

Screen Shot 2020-05-21 at 1 36 56 pm
atanisoft commented 4 years ago

@patfelst decode the backtrace to narrow the cause further

patfelst commented 4 years ago

Do you mean with this https://github.com/me-no-dev/EspExceptionDecoder ?

thanks I will try that on the weekend, I saw reference to that too, but will have to figure out how to use it.

atanisoft commented 4 years ago

@patfelst yes, if you add that plugin (or use one of the other command line versions) you can paste the Backtrace: XXXX line into the decoder and it should return the decoded details which should point to the specific lines in the code that are causing the LoadProhibited (which usually means a null dereference or out-of-memory condition)

patfelst commented 4 years ago

Thanks @atanisoft that enabled me to solve the problem. Nothing to do with bluetooth, it was a sprintf %s being passed a char instead of a string. Enough to crash the micro!!

stale[bot] commented 4 years ago

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] commented 4 years ago

[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.