2020-07-27 06:57 AM
2020-07-27 08:13 AM
go to debug mode and look at usart, gpio and sys/rcc registers for clock enable. track down the issue
2020-07-27 08:41 AM
Enable the usart1 clock. Generate code with stm32cubemx to do this for you. Show your code.
2020-07-27 12:09 PM
2020-07-27 12:12 PM
The register of USART1 always zero except for the ISR=c0
2020-11-23 08:58 AM
I am encountering the same error; all other UARTs are working, using Nucleo-L4R5ZI. USART1 CR1 remains at 0, even after the MODIFY_REG instruction is issued during initialization. I suspect that this has something to do with USART1 being on APB2 while all other USARTs are on APB1.
2020-11-23 09:12 AM
If all the USART's registers are ZERO, then the clock is likely not properly enabled. Try ENABLING it
Inspect the registers for the RCC and make a determination if it relates to APB1 vs APB2
Last time I check this was coded properly for the L4
__USART1_CLK_ENABLE();
__HAL_RCC_USART1_CLK_ENABLE
#define __HAL_RCC_USART1_CLK_ENABLE() do { \
__IO uint32_t tmpreg; \
SET_BIT(RCC->APB2ENR, RCC_APB2ENR_USART1EN); \
/* Delay after an RCC peripheral clock enabling */ \
tmpreg = READ_BIT(RCC->APB2ENR, RCC_APB2ENR_USART1EN); \
UNUSED(tmpreg); \
} while(0)
2020-11-23 10:26 AM
By manually calling __HAL_RCC_USART1_CLK_ENABLE(), I can see that USART1 CR1 is now changing to the expected value (one would not think this step necessary, as this happens in HAL_UART_MspInit as generated by CubeMx prior to any configuration being attempted).
I am still not getting transmissions through USART1. I can confirm that all registers are identical between USART1 and USART2; USART2 is working as expected. I have confirmed that the pin I am using for USART1 is functional when used as a GPIO in output mode.
The line does not idle high as expected; it is just constantly low.
I can confirm that USART1 is enabled in APB2ENR and NOT in reset state in APB2RSTR.
2020-11-23 12:31 PM
For all who are experiencing this issue, upgrading to the latest version of STM32CubeIDE (1.5.0) successfully resolved my issue. I was previously using 1.3.0. I presume this error was caused by some issue in the CubeMX-generated initialization code.
2020-11-25 12:28 PM
Hello dear friend!!!
I 've tried the suggestion of ST enginneer and used the the old version of STM32 CUBEMX Version 6.0.0
and the LPUSART worked properly.
Best regards