UART1 RAK3172 (STM32WLE5CCU6)

[samuelbs]

Hello, I’m facing an issue using the RAK3172. In my project, UART1 is configured for debugging and LoRaWAN logs, while UART1 (PB6/PB7) is reserved for communication with the LC76G GPS module.

However, I'm unable to print any data from the GPS module to the monitor. So, I performed two steps to verify whether the module is actually working:

1. I checked the current consumption using a multimeter;

2. I soldered a wire directly to the module's TX pin and used a TTL converter to confirm that NMEA data is indeed being sent.

Based on that, I searched the forum and saw that others have experienced issues with UART1 on this module, but I couldn’t find a clear solution.

These are the two functions I’ve implemented so far, and I’m calling them during the LoRa initialization. I’d like to point out that they were used successfully in a previous project with an STM32L4, and everything worked fine there.

void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size)
{
if (huart == &huart1)
{
printf(gpsData.rxDataBuffer);
}
}

void GPS_reset(GPIO_TypeDef *GPIOx, uint16_t pin)
{
HAL_GPIO_WritePin(GPIOx, pin, RESET);
HAL_Delay(500); // datasheet = 100ms, but this seemed too short
HAL_GPIO_WritePin(GPIOx, pin, SET);
printf("RESET DONE\n");
}

[samuelbs]

Hello,

I managed to find the solution. To do this, I found how the system works in the PDF: https://www.st.com/resource/en/application_note/an5406-how-to-build-a-lora-application-with-stm32cubewl-stmicroelectronics.pdf.

Basically, the stack operates with the sequencer scheduling the tasks. With that in mind, I followed these steps:

1. Created a new task;

2. Called the task when needed (in my case, when the GPIO is triggered);

3. Reinitialized UART1, and that was it.

Now I plan to implement UART1 with DMA, but for now, this is already working great for me.

I hope this helps someone else as well. Just a reminder: the PDF contains the most valuable information on how the system works.

[Dana Myers]

I have no problem with the RAK3172 modules on the RAK5005 carrier board; I have 300+ such devices in production using firmware developed with STM32CubeIDE. I suggest checking the pin assignments for the RAK3172, they differ from the ST example code.

Good luck.