For atClient applications, you can only call APIs like “le_atClient_SetCommand()” or “le_atClient_SetCommandAndSend()” to fill your AT command string without “\r\n”. For example for the command “AT\r\n”, you just need call le_atClient_SetCommand(cmdRef, “AT”).
No need to add “\r” or “\r\n” at the end of the command string. atClient service will auto-matically apend “\r” at the end of the AT command string passed to “le_atClient_SetCommand()" or “le_atClient_SetCommandAndSend()”. You can refer to the sample code atClientTest.c in legato/apps/test/atServices/atClientTest/atClientTestComp for more details.
I don’t remember if the “\n” is apended by atClient Service code. I have never received such issue before. Is the UART1 connected to a sierra modem’s AT parser, or your own AT parser ? It could be an AT parser issue if connected to your own AT parser (your AT parser need support AT command started with “\n").
It is connected to an ESP32 AT parser. The ESP32 AT parser does not support commands starting with a ‘\n’ character thus it returns an error, or the uart on the esp32 simply gets stuck. I do not believe this is intended behaviour, starting commands with a newline is not documented anywhere for AT command client in legato docs.
Sorry, my mistake !
“0x0D” is ‘\r’ . Yes, atClient Service will apend ‘\r’ to each AT command string, so when you pass “AT” to le_atClient_SetCommand(), atClient Service will echo string “AT\r” to AT parser, this is designed behavior.
It’ very strange ,why the ‘\r’ is sent before the command in your log ? In atClient code, we DO apend ‘\r’ to the comand string as below:
You are correct. I also sometimes mix up 0D with 0A…
But as you see in all my logs, ‘\r’ is always prepended before the command. So string “AT” will become “\rAT” instead of:
I have no idea what could be causing this, but if we assume the legato code contains no errors then it has to be in the UART1 driver, or maybe I am initializing some memory for holding the command string wrong?
Do you have suggestions on correct initialization for UART1 driver? If you have a few minutes spare maybe you can test/try my usecase. Note that I am using /dev/tty/HS0 instead the ‘standard’ /dev/tty/AT interface!
ps. I appreciate your help so far, it is good to have somebody thinking with me!
Yes, agree with you. It should be a UART1 driver issue ( maybe on ESP32 side) rather than a legato issue. You need first debug the UART1 port. For example check if the UART1 parameters are configured properly in your application and the module.
A simple way is stop legato and then run shell commands like " echo “AT” > /dev/ttyHS0 " or “microcom /dev/ttyHS0” and then check if expected command string is received on ESP32 .
Your comments made me investigate the reliability of the serial terminal program I was using. So to confirm that the issue was not on Legato side I hooked up the WP76 to a logic analyser. I was very surprised to see that the WP76 was indeed sending the right string of characters, and the issue was in my terminal program (which I have used for two years without any issues!). Nevertheless, the ESP32 could not handle the line endings of the Legato AT client. The error codes I saw previously where not connected to the output of my serial program. I made a mistake in thinking these two issues were connected, thus I blamed Legato.
I managed to solve this issue as well by modifying the line endings of the ESP32 stack. Communication between the two devices is now fully functional.