UART reading problem
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-31 1:51 AM
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
- Labels:
-
STM32WL series
-
UART-USART
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-31 2:40 AM
Do you handle​ UART errors, mainly overflows?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-31 11:19 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-08-01 11:35 AM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-08-01 11:35 AM
Thanks for answer! No I do not, please, how can I do that?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-08-01 11:41 AM
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"
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-08-01 11:42 AM
>>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
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-08-01 12:38 PM
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?
