UART reading problem

[Foreen]

Hello,

I have STM32WLE5CBU6 and I communicate with my Quectel chip over standard UART communication (interface LPUART, PA2, PA3) via AT commands.

Transmitting from STM to Quectel is always working well, but when I want to read response from Quectel chip, it in most cases does not work. Strange thing is that it sometimes after startup works (< 1 % of cases), however I do not have an idea why it sometimes works and sometimes does not.

The behavior is the same all the time from power on:

• When it receives correctly first AT response, it receives correctly any other response.
• When it does not receive correctly first AT response, it does not receive correctly any other response.

Sometimes it is ok the whole day, but when I try it again after a day, it stops working.

I have tried:

• Changing domain voltage on Quectel chip (3,3 V and 1.8 V)
• Connecting oscilloscope to RX of STM - voltage levels seems to be ok
• Connecting CH340 in parallel - CH340 reads correctly all responses from Quectel chip and STM does not

Anybody knows, how to solve it?

Hardware connection:

• No pull ups
• 2.2 k resistor between STM and Quectel (CH340 and oscilloscope were measuring after resistor as well as STM is)

I am sending and receiving data with these commands:

const uint8_t AT_Tx[] = "AT\r";
uint8_t AT_Rx[16];
 
HAL_UART_Transmit_IT(&hlpuart1, AT_Tx, sizeof(AT_Tx));
HAL_UART_Receive(&hlpuart1, AT_Rx, sizeof(AT_Rx), 300);

This is my setup of hlpuart1:

hlpuart1.Instance = LPUART1;
hlpuart1.Init.BaudRate = 115200;
hlpuart1.Init.WordLength = UART_WORDLENGTH_8B;
hlpuart1.Init.StopBits = UART_STOPBITS_1;
hlpuart1.Init.Parity = UART_PARITY_NONE;
hlpuart1.Init.Mode = UART_MODE_TX_RX;
hlpuart1.Init.HwFlowCtl = UART_HWCONTROL_NONE;
hlpuart1.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
hlpuart1.Init.ClockPrescaler = UART_PRESCALER_DIV1;
hlpuart1.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
hlpuart1.FifoMode = UART_FIFOMODE_DISABLE;
if (HAL_UART_Init(&hlpuart1) != HAL_OK)  {Error_Handler();}
if (HAL_UARTEx_SetTxFifoThreshold(&hlpuart1, UART_TXFIFO_THRESHOLD_1_8) != HAL_OK) {Error_Handler();}
if (HAL_UARTEx_SetRxFifoThreshold(&hlpuart1, UART_RXFIFO_THRESHOLD_1_8) != HAL_OK){Error_Handler();}
if (HAL_UARTEx_DisableFifoMode(&hlpuart1) != HAL_OK) {Error_Handler();}

In CubeMX:

• NVIC interrupt is checked

[waclawek.jan]

Do you handle​ UART errors, mainly overflows?

[Johi]

Can you be more specific regarding "it does not work", do you receive any characters, or nothing at all?

It could be that you are expecting 16 bytes but the device is not sending 16 bytes. Therefor try to read 1 character at a time and send it to your SWV ITM data console to trace the contents of the message in a short loop. Could also be that the timeout kicks in before you received all the data.

Other good experiment is the loopback: connect TX to RX and try to receive what you are sending reliably.

[Foreen]

Thanks for answer.

"it does not work" - buffer AT_Rx before and after HAL_UART_Receive is still the same (=random because of initialization without value)

Thanks, I will try it! Is it possible to send it directly via ST-Link V2 without debugging mode enabled?

Timeout is not the problem - I tried a way bigger time out and on parallel console I saw the response while STM was still waiting and after timeout it did not receive anything.

Also good idea, thanks, I will try it!

Meanwhile I figure out that when I set a way bigger CPU clock frequency (24 MHz instead of 0.4 MHz), it starts working, is it possible?

[Foreen]

Thanks for answer! No I do not, please, how can I do that?

[Tesla DeLorean]

Should set the non-blocking receive operation up using the interrupt / IT method in the *expectation* of getting data, and buffer in the call-back routine.

Might expect modems to want "\r\n"

[Tesla DeLorean]

>>Meanwhile I figure out that when I set a way bigger CPU clock frequency (24 MHz instead of 0.4 MHz), it starts working, is it possible?

Low frequencies will limit achievable baud rate clocks, half expect initialization to error

[Foreen]

Thanks! Is it possible to somehow handle the initialization error? I need to have really low power consumption, so I need to have lower frequency (at least 2 MHz - LPrun). Do you thinkg that setting higher frequency for initialization and lower frequency after initialization would help? What if I set higher frequency just for UART, would it work?