AT commands via UART, STM32F4 -- ESP8266

[Sde K.1]

Hello everbody!

Im new to the STM32 platfor, and i want to learn about it. For a personal project i want to make de device that tracks a crypto valuta. Just for fun.

I have a ESP8266 with the AT firmware, and I could send commands via FTDI using putty. Now I could like to use the STM32 to do that. I have the ESP connected to UART2 (PA2 and PA3).

I have setup a full speed USB port on pin PA11 and PA12 and made it a COM Port.

I found this post about AT and tried some of it. It kinda works... But I think it is waiting at those HAL Transmit and Receive line. Because the LED's stop blinking. And the com port stops working, sometime i get a respone in putty.

I was hoping someone could help me out with this problem.

Thanks!

int main(void)
{
  HAL_Init();
 
  SystemClock_Config();
  MX_GPIO_Init();
  MX_USB_DEVICE_Init();
  MX_USART2_UART_Init();
 
  char data[] = "AT\r\n"; //I want send: AT
  char rsp[7]; //I expect the response OK: \r\nOK\r\n, six character + NUL
  while (1)
  {
	  HAL_GPIO_TogglePin(GPIOA, LED_1_Pin);
	  HAL_GPIO_TogglePin(GPIOA, LED_2_Pin);
 
	  HAL_UART_Transmit(&huart2, (uint8_t*)data, strlen(data) , 1000); //Send command
 
//	  CDC_Transmit_FS(data, sizeof(data)); //Show the command sent on serial monitor
	  memset(rsp, 0, sizeof(rsp)); // Clear buffer
	  HAL_UART_Receive(&huart2, (uint8_t*)rsp, strlen(rsp)-1, 1000);
	  CDC_Transmit_FS((uint8_t *) rsp, strlen(rsp)); //Show the response on serial monitor
	  HAL_Delay(1000);
 
  }
}

[Sde K.1]

Im trying to get a response, this is the best i get back:

[RomainR.]

I propose you an example I developed with a NucleoL452 and an ESP-WROOM-02 with a USART1, PA9 & PA10 AT Command.

This solution will work with an usual ESP8266 in AT mode in the same way.

this should help you

https://github.com/rreicher/NucleoL452RE_EspWroom_Ubidots

[Sde K.1]

I figured out that the response of the ESP is much longer than just "OK\r\n".

The response is made up of two parts, 1) the line I just send , 2) the actually response.

So the response is "AT\r\r\nOK\r\n".

I had to use a bigger char array to store all the data.

    char data[] = "AT\r\n";
    char Rx_data[11]; //I expect the response OK: \r\nOK\r\n, six character + NUL
	  
    HAL_UART_Transmit(&huart2, data, 4 , 100); //Send command
    HAL_UART_Receive(&huart2, Rx_data, 11, 1000);

Still I find this a bit strange. But maybe this is just the way it should work.

[Sde K.1]

Thank you for the input, my level of C is not up to your standard, but it is good to have some example and reference.

[Andrew Neil]

"The response is made up of two parts, 1) the line I just send , 2) the actually response."

So that means you have Echo turned on. ATE0 will turn it off.

see: https://www.avrfreaks.net/comment/2928456#comment-2928456

The Echo is not really part of the response.

see: https://www.avrfreaks.net/comment/2305996#comment-2305996

Again, these are the kinds of things that you can explore more easily with a terminal - rather than in your firmware.

"maybe this is just the way it should work"

Yes, it is.

https://www.avrfreaks.net/comment/2212166#comment-2212166

[RomainR.]

Dear Sde K.1,

You have to manage ESP response by using HAL_UART_Receive_IT() one byte at a time, because the response to different AT+CMD have variable lenghts.

This is precisely what my project does by using ring buffer to store incoming response from ESP.

Let me know if you need help with this code.

BR

[Andrew Neil]

"You have to manage ESP response ... one byte at a time"

+1 - just as @Community member​ said earlier.

"the response to different AT+CMD have variable lenghts"

in fact, responses to the same AT Command can have different lengths.

[Sde K.1]

I been working on it for a bit now.

And as @RomainR.​ pointed out I needed to use HAL_UART_Receive_IT() . I got that working, and when i connected a FTDI adapter to the STM, I could recieve data via putty, one byte at a time. But I can't recieve data from the ESP. I send the AT\r\n command, but the interrupt callback is not called. Im not sure why the ESP data is not coming in.

Also i just connected like so:

SMT Tx -- ESP Rx

ESP Tx -- FTDI Rx

And i sended the AT\r\n command from the SMT to the ESP and on my pc in putty I got the OK command back, so the ESP is responding.

#include "main.h"
#include "usb_device.h"
#include "usbd_cdc_if.h"
 
UART_HandleTypeDef huart1;
 
void SystemClock_Config(void);
static void MX_GPIO_Init(void);
static void MX_USART1_UART_Init(void);
 
char Rx_Byte[1];  		// Creating a single byte buffer
uint8_t Rx_Buffer[256];	// Full buffer
uint8_t Rx_Buffer_Index = 0;
 
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart){
 
    HAL_UART_Receive_IT(&huart1, (uint8_t *)Rx_Byte, 1);
    memcpy(Rx_Buffer + Rx_Buffer_Index, Rx_Byte, 1);
    Rx_Buffer_Index++;
    if (*Rx_Byte == '\r' || *Rx_Byte == '\n') {
// I could send data via putty and FTDI, and when enter was pressed it printed the data in the buffer back to you via uart
//        HAL_UART_Transmit(&huart1, (uint8_t *) Rx_Buffer, Rx_Buffer_Index, 1000);  
        memset(Rx_Buffer, 0, sizeof(Rx_Buffer)); // Clear buffer
        Rx_Buffer_Index = 0;
    }
}
 
int main(void)
{
 
  HAL_Init();
 
  SystemClock_Config();
 
  MX_GPIO_Init();
  MX_USART1_UART_Init();
  MX_USB_DEVICE_Init();
 
  char echo_off[] = "ATE0\r\n";
  char data[] = "AT\r\n";
  HAL_Delay(1000);
  HAL_UART_Transmit(&huart1, (uint8_t*)echo_off, sizeof(echo_off), 10);
 
  while (1)
  {
	  HAL_GPIO_TogglePin(GPIOA, LED_1_Pin);
	  HAL_UART_Transmit(&huart1, (uint8_t*)data, sizeof(data), 1000);
	  HAL_Delay(500);
  }
}

[Andrew Neil]

@Sde K.1​ "I send the AT\r\n command"

As previously noted, you don't need the \n on a command - so start by getting rid of that, as it may be confusing the issue.

" i just connected like so: SMT Tx -- ESP Rx; ESP Tx -- FTDI Rx"

Are you sure that's correct? with "modem" devices (like the ESP) "Rx" and "TX" may be reversed ...

Again, you could easily test this by connecting the ESP to your PC terminal - see which way around works.

Do you have an oscilloscope or logic analyser to see what's happening on the wire?

See https://www.avrfreaks.net/comment/2336161#comment-2336161 for some serial debug tips - follow the links for how to use two terminals to see "both sides" of the conversation.