I am using an ESP32 to capture some data and then sending it over using ArduinoJson. However, sometimes, the firmware gets stuck at the line where it is transmitting data at obj.printTo(client). I have the logs for the same. Do you have any idea as to what might be making it freeze? And any way to avoid it in the future.


12:28:00.584 -> [V][ssl_client.cpp:276] send_ssl_data(): Writing HTTP request...

12:28:00.584 -> [V][ssl_client.cpp:276] send_ssl_data(): Writing HTTP request...
12:47:11.229 -> [E][ssl_client.cpp:33] handle_error(): UNKNOWN ERROR CODE (004E) 12:47:11.229 -> [E][ssl_client.cpp:35] handle_error(): MbedTLS message code:-78

12:47:11.229 -> [V][ssl_client.cpp:245] stop_ssl_socket(): Cleaning SSL connection.
12:47:11.229 -> request sent
12:47:12.217 -> esp32/Arduino CI has failed
12:47:12.217 -> reply was: 12:47:12.217-> ==========
12:47:12.217 ->
12:47:12.217 -> ==========
12:47:12.217 -> closing connection

The send code:

JsonObject &rootObject = jsonBuffer.createObject();
JsonObject &dataObject = rootObject.createNestedObject("data");
JsonArray &X1dataObject = dataObject.createNestedArray("X1");
JsonArray &Y1dataObject = dataObject.createNestedArray("Y1");
JsonArray &Z1dataObject = dataObject.createNestedArray("Z1");
JsonArray &T1dataObject = dataObject.createNestedArray("T1");


if (send_flag) {
  send_flag = false;
  int connection_iterator = 0;
  int connection_iterator2 = 0;
  for (int iterator = 0; iterator < SAMPLE_SIZE; iterator++) {

  rootObject["coreid"] = String(low, HEX) + String(high, HEX);
  //rootObject["coreid_high"] = String(high, HEX);
  rootObject["sample_time"] = int(time_taken);
  rootObject["firmware_version"] = FIRMWARE_UPDATE_VERSION;
  Serial.print("connecting to ");
  while ((!client.connect(host, httpsPort)) && !setup_mode) {
    Serial.println("connection failed! Retrying..");
    if (connection_iterator >= 10)
  if (client.verify(fingerprint, host)) {
    Serial.println("certificate matches");
  } else {
    Serial.println("certificate doesn't match");
  digitalWrite(LED_BUILTIN, HIGH);
  Serial.print("requesting URL: ");
  client.println(String("POST ") + url + " HTTP/1.0");
  client.println(String("Host: ") + host);
  client.println("Cache-Control: no-cache");
  client.println("Content-Type: application/json");
  client.print("Content-Length: ");
  Serial.println("NUMBER OF INTERRUPTS:");
  Serial.println("request sent");
  while ((client.connected()) && !setup_mode) {

    String line = client.readStringUntil('\n');
    if (line == "\r") {
      Serial.println("headers received");
    Serial.println("Waiting for response");
    if (connection_iterator2 >= 40)
  String line = client.readStringUntil('\n');
  if (line.startsWith("{")) {
    Serial.println("esp32/Arduino CI successfull!");
  } else {
    Serial.println("esp32/Arduino CI has failed");
  Serial.println("reply was:");
  Serial.println("closing connection");
  digitalWrite(LED_BUILTIN, LOW);
  // readRegister(INT_SOURCE, 1, &dummy_read);

2 Answers 2


I see that you are using SSL. SSL uses a lot of RAM and it is possible that the stack and the heap are colliding which will corrupt the running sketch. I recommend you add the amount of free heap to your log statements so that you can see how it changes, which will help you see if this is what is happening.

To obtain the free heap you can use esp_get_free_heap_size() - there's more documentation about this function in the espressif online documentation.

  • I will surely log the heap size but this doesn't seem to be happening as the code is not getting corrupted or even crashing. Just that after some time it throws a handle_error and resumes to what it should be doing. However, I will still log the heap size and watch the deviations. Apr 26, 2019 at 15:38
  • I did the testing and the heap doesn't seem to be the issue. After a successful transfer, there is still about 75% of the heap memory available. Apr 26, 2019 at 17:45
  • @peeyushtekriwal I think you'll need to post your code for anybody to be able to help you further.
    – Phil Haigh
    Apr 29, 2019 at 9:25
  • Understandable. I will add the code above Apr 29, 2019 at 10:19

So I have found out that apparently there is some issue working with WiFiClientSecure to send large data packets. The secure line sends data in small packets which take up a lot of time and also if the server gets unavailable at any moment, the program will get stuck there. This problem, however, was not this prominent when I used the same mechanism in esp8266. Nevertheless, the solution would be to use a buffer to send the data.

Also, this version of code was written with ArduinoJson V5. But, even after migrating to ArduinoJson V6 the problem persists. It seems that whatever new JsonDocument feature has been implemented in the new version is still far from providing the efficiency of a buffer and it recoils back.

However still, if anyone else finds a better solution, please do update.

  • Latest development: I picked up this issue after a long time after not being able to solve it and still cannot find any leads. The chip seems to establish a connection with the server but somehow, it gets stuck and is unable to continue. The point to be noted is that the same mechanism is working with ESP8266. Jun 24, 2019 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.