When ECHO is deactivated and try to send random AT command AT+CSQ for example using dce->at(). at() returns OK but the response is corrupted. (IDFGH-11753)

[franz-ms-muc]

Answers checklist.

• I have read the documentation for esp-protocols components and the issue is not addressed there.
• I have updated my esp-protocols branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Hello Franz,

I’ve found an issue in esp_modem_command_library.cpp

When ECHO is deactivated and try to send random AT command AT+CSQ for example using dce->at().

at() returns OK but the response is corrupted.

Here is the LOG:

D (70408) usb_terminal: 0x3fcf68c8   41 54 2b 43 53 51 0d                              |AT+CSQ.|
D (70408) CDC_ACM: Submitting BULK OUT transfer
D (70408) CDC_ACM: out/ctrl xfer cb
D (70408) CDC_ACM: in xfer cb
D (70408) usb_terminal: 0x3fc9a014   0d 0a 2b 43 53 51 3a 20  32 35 2c 39 39 0d 0a     |..+CSQ: 25,99..|
D (70418) CDC_ACM: Submitting poll for BULK IN transfer
D (70428) CDC_ACM: in xfer cb
D (70428) usb_terminal: 0x3fc9a023   0d 0a 4f 4b 0d 0a                                 |..OK..|
D (70438) CDC_ACM: Submitting poll for BULK IN transfer
I (70458) MODEM_COM_LIB: INTEGER ERROR: NO Match exits for -> �?ts�?25,99

As you can see beginning of the string is corrupted, this way we can’t correctly parse the command response.

I think that this is caused by usage of std::string_view inside generic_get_string().

It looks like the beginning of the data buffer is overrided between return of the lambda function and actual return of t->command().

Since std::string_view represents a view of the data(means keep only pointer) we must be sure that the object which contains the data is preserved and data is not changed until it is copied into the new string object.

Current implementation is really error-prone and need to be updated.

Currently I always activate ECHO(ATE1) but this is very bad workaround.

Can you please inform Espressif about this problem.

Maybe describing where the problem comes from will help them fix it faster.

[david-cermak]

Thanks for the report! You're right, we should copy the string content here:

esp-protocols/components/esp_modem/src/esp_modem_command_library.cpp

Line 73 in a6845f4

output = token;

rather than use std::string_view assignment.