+IPD adding linebreaks?

[aferran]

Hello,

I'm using an esp32 on custom board based on a TI am335x uC, and I'm using AT commands to control it.

Everything seems to work fine, but when I'm sending a http request using AT+CIPSEND, and read the response after +IPD, it seems that there is an extra line break after each lines, which prevent curl to parse the answer properly (see example below.). Is there a way to prevent that?
I'm using:

AT version:1.0.0.0(870285c - Nov 14 2017 07:26:38)
SDK version:v2.1-65-g8bca703
compile time:Nov 17 2017 07:53:25
Bin version(Wroom32):1.0.0

Thanks,

Antoine

HTTP response example:

Code: Select all

HTTP/1.1 200 OK

X-Powered-By: Express

Access-Control-Allow-Origin: *

Content-Type: application/json; charset=utf-8

Content-Length: 16

ETag: W/"10-c2PoX+nt7m8FOksxlYjAhg"

X-Response-Time: 0.544ms

Vary: Accept-Encoding

Date: Thu, 21 Dec 2017 17:15:24 GMT

Connection: keep-alive



{"success":true}

What I'm expecting:

Code: Select all

HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 16
ETag: W/"10-c2PoX+nt7m8FOksxlYjAhg"
X-Response-Time: 0.544ms
Vary: Accept-Encoding
Date: Thu, 21 Dec 2017 17:15:24 GMT
Connection: keep-alive

{"success":true}


[ESP_Faye]

Hi,

+IPD will not add any data into the original data received from internet.
It should be your original data has the line break.
Or you can test it with any TCP tool on your PC to check if there are still line breaks.

Thanks for your interest in ESP8266!

[aferran]

Hi,
Thanks for your answer.
I have sent the same request from my PC and from the board, and dumped the result in HEX format.
It seems that the data after +IDP command has \n\n at the end of every line instead of \r\n (see the dump below, I have highlighted the differences).

I also added the code sample I use to parse the +IPD command if that can be of any help.

Best Regards,

Antoine

Sample code:

Code: Select all

static size_t read_data(void *ptr, size_t size)
{
   size_t read=0;
   size_t rd_buffer_len=0;
   char* rd_line = NULL;
   size_t len =0, i=0;
   (void)size; // TODO: Handle buffer size

   static FILE* fp=NULL;

   if (fp==NULL)
   {
      fp=fdopen(ESP8266_FD, "r");
   }

   read = getdelim(&rd_line, &len, '+', fp);
   printf("esp32:%s", rd_line);

   read = getdelim(&rd_line, &len, ':', fp);
   printf("esp32:%s", rd_line);

   if (!strncmp(rd_line,"IPD",3))
   {
      sscanf(rd_line,"IPD,%d:",&rd_buffer_len);
   }

   if(rd_buffer_len>0)
   {
      printf("esp32: Data length:%d\n", rd_buffer_len);
      read=fread(ptr,1,rd_buffer_len,fp);

// Dumping in HEX
      for(i=0; i<read; i++)
      {
         printf("%02X",((unsigned char*)ptr)[i]);
      }
   }

   if(rd_line)
   {
      free(rd_line);
   }

   return read;
}


HEX dump from +IPD:

00000000 48 54 54 50 2F 31 2E 31 20 32 30 30 20 4F 4B 0A 0A 58 2D 50 6F 77 65 72 HTTP/1.1 200 OK..X-Power
00000018 65 64 2D 42 79 3A 20 45 78 70 72 65 73 73 0A 0A 41 63 63 65 73 73 2D 43 ed-By: Express..Access-C
00000030 6F 6E 74 72 6F 6C 2D 41 6C 6C 6F 77 2D 4F 72 69 67 69 6E 3A 20 2A 0A 0A ontrol-Allow-Origin: *..
00000048 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 61 70 70 6C 69 63 61 74 69 6F Content-Type: applicatio
00000060 6E 2F 6A 73 6F 6E 3B 20 63 68 61 72 73 65 74 3D 75 74 66 2D 38 0A 0A 43 n/json; charset=utf-8..C
00000078 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 3A 20 31 36 0A 0A 45 54 61 67 3A ontent-Length: 16..ETag:
00000090 20 57 2F 22 31 30 2D 63 32 50 6F 58 2B 6E 74 37 6D 38 46 4F 6B 73 78 6C W/"10-c2PoX+nt7m8FOksxl
000000A8 59 6A 41 68 67 22 0A 0A 58 2D 52 65 73 70 6F 6E 73 65 2D 54 69 6D 65 3A YjAhg"..X-Response-Time:
000000C0 20 30 2E 33 31 33 6D 73 0A 0A 56 61 72 79 3A 20 41 63 63 65 70 74 2D 45 0.313ms..Vary: Accept-E
000000D8 6E 63 6F 64 69 6E 67 0A 0A 44 61 74 65 3A 20 54 68 75 2C 20 32 38 20 44 ncoding..Date: Thu, 28 D
000000F0 65 63 20 32 30 31 37 20 31 30 3A 32 35 3A 33 33 20 47 4D 54 0A 0A 43 6F ec 2017 10:25:33 GMT..Co
00000108 6E 6E 65 63 74 69 6F 6E 3A 20 6B 65 65 70 2D 61 6C 69 76 65 0A 0A 0A 0A nnection: keep-alive....
00000120 7B 22 73 75 63 63 65 73 73 22 3A 74 72 75 65 7D 20 {"success":true}

Wireshark dump from my PC:

0000 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK.
0010 0a 58 2d 50 6f 77 65 72 65 64 2d 42 79 3a 20 45 .X-Powered-By: E
0020 78 70 72 65 73 73 0d 0a 41 63 63 65 73 73 2d 43 xpress..Access-C
0030 6f 6e 74 72 6f 6c 2d 41 6c 6c 6f 77 2d 4f 72 69 ontrol-Allow-Ori
0040 67 69 6e 3a 20 2a 0d 0a 43 6f 6e 74 65 6e 74 2d gin: *..Content-
0050 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f Type: applicatio
0060 6e 2f 6a 73 6f 6e 3b 20 63 68 61 72 73 65 74 3d n/json; charset=
0070 75 74 66 2d 38 0d 0a 43 6f 6e 74 65 6e 74 2d 4c utf-8..Content-L
0080 65 6e 67 74 68 3a 20 31 36 0d 0a 45 54 61 67 3a ength: 16..ETag:
0090 20 57 2f 22 31 30 2d 63 32 50 6f 58 2b 6e 74 37 W/"10-c2PoX+nt7
00a0 6d 38 46 4f 6b 73 78 6c 59 6a 41 68 67 22 0d 0a m8FOksxlYjAhg"..
00b0 58 2d 52 65 73 70 6f 6e 73 65 2d 54 69 6d 65 3a X-Response-Time:
00c0 20 30 2e 33 31 32 6d 73 0d 0a 56 61 72 79 3a 20 0.312ms..Vary:
00d0 41 63 63 65 70 74 2d 45 6e 63 6f 64 69 6e 67 0d Accept-Encoding.
00e0 0a 44 61 74 65 3a 20 54 68 75 2c 20 32 38 20 44 .Date: Thu, 28 D
00f0 65 63 20 32 30 31 37 20 31 30 3a 31 32 3a 30 31 ec 2017 10:12:01
0100 20 47 4d 54 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e GMT..Connection
0110 3a 20 6b 65 65 70 2d 61 6c 69 76 65 0d 0a 0d 0a : keep-alive....
0120 7b 22 73 75 63 63 65 73 73 22 3a 74 72 75 65 7d {"success":true}

[aferran]

Hello again,

Any updates on this issue?

Thanks!

Antoine

[aferran]

Hello,

After further investigations, it seems that my issue could be caused by the tty configuration in my program, especially the ICRNL, INLCR, OCRNL and ONLCR flags.
Would it be possible to have an example of a tty configuration that works properly with the AT commands? Please find below the configuration I'm using.

Thanks,

Antoine

Code: Select all

   
   struct termios tty;
   memset (&tty, 0, sizeof tty);
   if (tcgetattr (fd, &tty) != 0)
   {
      fprintf (stderr, "error %d from tcgetattr", errno);
      return -1;
   }

   cfsetospeed (&tty, speed);
   cfsetispeed (&tty, speed);

   tty.c_cflag = (tty.c_cflag & ~CSIZE) | CS8;     // 8-bit chars
   // disable IGNBRK for mismatched speed tests; otherwise receive break
   // as \000 chars
   tty.c_iflag &= ~IGNBRK;         // disable break processing
   tty.c_lflag = 0;                // no signaling chars, no echo,
   // no canonical processing
   tty.c_oflag = 0;                // no remapping, no delays
   tty.c_cc[VMIN]  = 0;            // read doesn't block
   tty.c_cc[VTIME] = 5;            // 0.5 seconds read timeout

   tty.c_iflag &= ~(IXON | IXOFF | IXANY); // shut off xon/xoff ctrl

   tty.c_cflag |= (CLOCAL | CREAD);// ignore modem controls,
   // enable reading
   tty.c_cflag &= ~(PARENB | PARODD);      // shut off parity
   tty.c_cflag |= parity;
   tty.c_cflag &= ~CSTOPB;

   if (ESP8266_FLOW_CONTROL)
      tty.c_cflag |= CRTSCTS;
   else
      tty.c_cflag &= ~CRTSCTS;


   if (tcsetattr (fd, TCSANOW, &tty) != 0)
   {
      fprintf (stderr, "error %d from tcsetattr", errno);
      return -1;
   }



[aferran]

Mistery is solved!

It was indeed the tty configuration that was messing things up.
I had to switch to raw mode with cfmakeraw() before receiving data.

I hope that will help others that may have the same issue!

Best Regards,

Antoine