Hello,
I’m trying to run the FreeRTOS cellular demo modified for STM32F429 using SIM7070G LTE modem.
The demo uses a published STM32 UART interface API here:
github_dot_com/aws/amazon-freertos/blob/feature/cellular/vendors/st/boards/stm32l475_discovery/ports/comm_if/comm_if_st.c
I’m using UART8 instead of UART4, therefore, I’ve changed defines on lines 56-59 as well as UART interrupt handler on line 333.
The initialization completes successfully, however when the HAL_UART_Transmit_IT() is executed on line 533 it always returns HAL_BUSY and it drops to timeout count down on line 569, that runs out, transmit is retried for 2 more times and then the whole app gives up saying communication timeout.
I’ve tested UART8 interrupt transmit on a different application and it works well - the modem receives and responds to AT commands.
Couple of notes:
UART8_IRQHandler() is not called.
HAL_UART_TxCpltCallback() is not called.
HAL_UART_ErrorCallback() is not called.
My knowledge is limited and I am not sure where to debug further…
One more question:
line 421 has:
pIotCommIntfCtx->pPhy = & _iotCommIntfPhy;
However, line 138 has only one assignment:
static UART_HandleTypeDef _iotCommIntfPhy = { 0 };
Please be more precise. Is that diffrent software on the same hardware, or other or compatible software on a demo board vs. your custom hardware? The closer you can encircle what the differences between the working and non worlking scenarios are, the faster the cmmunity can help you.
I’ve tested a different software (created a new project under STM32CubeIDE) on the same hardware (stm32f429-disc1 eval kit) in order to confirm, that the hardware works OK.
ok, my strategy in this case would be to set a bp on the first tx invocation on both platforms, dump the contents of all UART and NVIC configuration registers (depending on what IDE you use, this may be trivial all the way up to cumbersome) and then compare the outputs. That should give you a clear picture fairly fast.
Meanwhile, if anyone ever tried cellular example on STM32 - please let me know if it worked out of the box. I see there was some problem raised in a different thread, but no solution provided:
forumsdotfreertosdotorg/t/stm32-freertos-issue-when-using-hal-uart-transmit-it/14923
In my experience, most developers sooner or later abandon the ST HAL. It is unnecessarily complicated, not very well designed and has a number of nasty implementation details that make it hard to integrate into other eco systems and architectures.
Some trust CMSIS, IDE generated or third-party libs more, others write their own peripheral drivers.
UART8 doesn’t support RTS/CTS, so maybe the HAL is smart enough to reject the init request. This code sets up RTS/CTS. Funny thing, the data sheet indicates UART4 doesn’t support RTS/CTS either.