cancel
Showing results for 
Search instead for 
Did you mean: 

UART1 RAK3172 (STM32WLE5CCU6)

samuelbs
Associate III

 

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");
}

 

11 REPLIES 11
Karl Yamashita
Principal

Test the UART1 in loopback. Short the Tx to the Rx pins and send some data. You should be able to get calls to  HAL_UARTEx_RxEventCallback. If not, then you have some configurations to look at. Worse case, damaged peripheral.

I was told that if a devices starts to smoke, put the smoke back in. I guess I never got all the smoke because the device never worked afterwards.
Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!

If you find my solution useful, please click the Accept as Solution so others see the solution.

Hi Karl, thank you for your response.

 

I’ll run the test and get back to you with feedback later. But I believe it might be something related to configuration, since I have two different projects that use the GPS on UART1 and both are showing the same issue.

 

Also, just for reference: in order to use the ADC with DMA, I had to reinitialize it every time before using it, and I saw that some people did something similar with UART, but I haven’t had any success with that so far…

 

Looking forward to your reply. Talk to you soon.

Looks like you're using HAL_UARTEx_ReceiveToIdle_DMA?

See my signature with a tutorial that shows how to configure the USART. 

I was told that if a devices starts to smoke, put the smoke back in. I guess I never got all the smoke because the device never worked afterwards.
Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!

If you find my solution useful, please click the Accept as Solution so others see the solution.
Karl Yamashita
Principal

Edit: replied to wrong post

I was told that if a devices starts to smoke, put the smoke back in. I guess I never got all the smoke because the device never worked afterwards.
Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!

If you find my solution useful, please click the Accept as Solution so others see the solution.

Hi Karl, I'm sending the IOC file attached. If you need anything else, please let me know.

I'll watch the videos and get back to you with feedback. But I’ll only be able to test later today, as I’m working off-site.


Hello Karl,

I was able to watch the video and run the tests. The configurations appear to be correct. As I mentioned earlier, I believe the issue is some bug in ST’s stack, given other users’ reports.

I’m still searching for a possible solution. I’m trying something like reinitializing again, just as I did with the ADC (code below):

uint32_t ADC_readChannels(uint32_t channel)
{
static volatile uint32_t adc_dma_val = 0;
ADC_ChannelConfTypeDef sConfig = {0};

MX_ADC_Init();

sConfig.Channel = channel;
sConfig.Rank = ADC_REGULAR_RANK_1;
sConfig.SamplingTime = ADC_SAMPLINGTIME_COMMON_1;

if (HAL_ADC_ConfigChannel(&hadc, &sConfig) != HAL_OK)
{
printf("Erro ADC ConfigChannel\r\n");
return 0;
}

if (HAL_ADC_Start_DMA(&hadc, (uint32_t*)&adc_dma_val, 1) != HAL_OK)
{
printf("Erro ADC Start DMA\r\n");
return 0;
}

HAL_ADC_DeInit(&hadc);
return adc_dma_val;
}


@samuelbs wrote:

Hi Karl, I'm sending the IOC file attached. If you need anything else, please let me know.

I'll watch the videos and get back to you with feedback. But I’ll only be able to test later today, as I’m working off-site.



Sorry, i replied to the wrong thread when i asked for the IOC file, lol.

I was told that if a devices starts to smoke, put the smoke back in. I guess I never got all the smoke because the device never worked afterwards.
Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!

If you find my solution useful, please click the Accept as Solution so others see the solution.
samuelbs
Associate III

Hello,

I still haven’t been able to figure out why it’s not working. But one thing is certain: I’m completely disappointed with the STM32WL (RAK3172) programmed via STM32CubeIDE… It’s unbelievable that UART1 doesn’t receive anything. The connections are correct, the configurations are set, and I can see data coming out of the GPS TX, yet nothing is received by the module. I also don’t believe it’s a hardware issue, since two boards from different designs exhibit the same symptom.

Being it's a custom board with an STM32WLE5, you should contact RAK for help.  

I was told that if a devices starts to smoke, put the smoke back in. I guess I never got all the smoke because the device never worked afterwards.
Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!

If you find my solution useful, please click the Accept as Solution so others see the solution.