I can't send AT commands

[Francesco_]

Board: STM32 NUCLEO F103RB (MB1136 C-01)

Wire cable with ESP8266: UART1_tx (PA9) -> RX_ESP8266 and UART1_rx (PA10) -> TX_ESP8266

Hi all,

I try to send AT command between board and ESP8266, without success.

I send the command but I don't see no reply.

The UART baud rate is: 115200 baud.

Below the code:

char data[] = "AT\r\n"; //I want send: AT

char rsp[6]; //I expect the response OK: \r\nOK\r\n, six character

HAL_UART_Transmit(&huart1, (uint8_t*)data, strlen(data) , 10000); \\Send command

HAL_UART_Transmit(&huart2, (uint8_t*)data, strlen(data) , 10000); \\Show the command sent on serial monitor

HAL_Delay(100);

HAL_UART_Receive(&huart1, (uint8_t*)rsp, strlen(rsp), 10000); \\In rsp, i expect the respons: OK

HAL_UART_Transmit(&huart2, (uint8_t*)rsp, strlen(data) , 10000); \\Show the response on serial monitor

Can you help me?

[Danish1]

I suspect the problem is that your ESP8266 is sending the reply before stm32 is ready to receive any characters.

The HAL_*** libraries cover very simple "use-cases" in order to be easy to use.

But that means HAL_UART_Transmit() doesn't return until the last character has been loaded into the UART. And the UART doesn't start listening until execution actually reaches the HAL_UART_Receive(). Your HAL_Delay() makes it more likely that you won't see anything.

How might things be improved?

If you could use interrupt-based (or DMA-based, but the HAL routines are harder) reception, and start reception before sending AT then things might work. But it's not an easy program.

Also note that your ESP8266 might echo the "AT\r\n" before sending "OK". So it's worth allocating more space for the reply and then looking though what you actually received for the "OK" you want.

Hope this helps,

Danish

[Tesla DeLorean]

Send the output to the serial monitor first

strlen() only works on NUL terminated strings, so an empty buffer will not work with it, and the modem won't return NULs for you either.

Really need some interrupt based buffering, this HAL stuff is worthless

char data[] = "AT\r\n"; //I want send: AT

char rsp[7]; //I expect the response OK: \r\nOK\r\n, six character + NUL

HAL_UART_Transmit(&huart2, (uint8_t*)data, strlen(data) , 10000); \\Show the command sent on serial monitor

HAL_UART_Transmit(&huart1, (uint8_t*)data, strlen(data) , 10000); \\Send command

memset(rsp, 0, sizeof(rsp)); // Clear buffer

HAL_UART_Receive(&huart1, (uint8_t*)rsp, sizeof(rsp)-1, 10000); \\In rsp, i expect the respons: OK

HAL_UART_Transmit(&huart2, (uint8_t*)rsp, strlen(data) , 10000); \\Show the response on serial monitor

[Francesco_]

Thanks all,

@Community member​  I have implemented your code but received as response: AT. Why do I have this echo?

HAL_UART_Transmit(&huart1, (uint8_t*)data, strlen(data) , 10000); \\Send command

memset(rsp, 0, sizeof(rsp)); // Clear buffer

HAL_UART_Receive(&huart1, (uint8_t*)rsp, sizeof(rsp)-1, 10000); \\In rsp, i expect the respons: OK -> In rsp i received AT and not OK

[Tesla DeLorean]

Sorry not using the ESP8266, but most modems echo unless you send ATE0 to turn it off.

Perhaps you could tunnel a UART connection to the ESP8266 so you can walk it through via a terminal application.

[Francesco_]

I try to send the command AT trought serial monitor. In this case ESP8266 is connected at Arduino board with empty firmware. This is the response:

AT

OK

AT is echo and OK is the response, then \r\nAT\r\nOK\r\n+NUL. It should work if i set rsp[11]?

[Tesla DeLorean]

>>It should work if i set rsp[11]?

That's typically not how people manage responses from MODEMs, etc. Usually you'd have some state-full method to process/decode the byte stream

What happens when the response is ERROR, NO CARRIER, or something else?

[Piranha]

Another bug:

HAL_UART_Transmit(&huart2, (uint8_t*)rsp, strlen(data) , 10000); \\Show the response on serial monitor

> this HAL stuff is worthless

The most important phrase!

[Francesco_]

@Community member​, now i receive the response from modem, How would you handle communication between the two board?

[Tesla DeLorean · Accepted solution]

Between MODEMs and GPS/GNSS I typically have interrupt driven FIFO buffers to manage the serial ports in the immediate sense, and then have worker tasks/threads interact with the devices in the command/response sense. Have a function that sends the commands a waits for the response without blocking everything else.