2018-07-10 12:49 AM
When generating MX_USART1_UART_Init for a usart in HalfDuplex mode, the USART_InitStruct.HardwareFlowControl field remain uninitialized which leads to unpredictable behavior of the system. in my case the I2C DMA was triggered by USART DMA requests....
fix: adding the missing initialization fields in mcu/config/llConfig/USART-STM32F0xx_LLConfigs.xml fixes the issue.
I only fixed this for my F030F4 project, the same issue might also be present for other configurations/mcu's
regards
ingo
#stm32cubemx-bug-ll_usart_init #stm32cubemx-bug2018-07-11 06:42 AM
Hello
idonasch
Can you please precise which CubeMX version are you using?
Please share your ioc file to check this issue.
With Regards,
Imen
2018-07-11 12:49 PM
Sorry for not providing this information in the first place:
STM32CubeF0 Firmware Package V1.9.0 / 25-August-2017 STMcubeMX V1.0 Version 1.0 adding the missing HardwareFlowControl entries to 'mcu/config/llConfig/USART-STM32F0xx_LLConfigs.xml' fixed the problem (see attachment patch.txt). But this is not a complete fix! I only patched a few obviously missing entries in the supplied version and only for this mcu. issue was in Src/usart.c: ... <quote> void MX_USART1_UART_Init(void) { // <<<<<<<<<<< The following struct is left uninitalized >>>>>>>>>>>>>>> LL_USART_InitTypeDef USART_InitStruct; LL_GPIO_InitTypeDef GPIO_InitStruct; /* Peripheral clock enable */ LL_APB1_GRP2_EnableClock(LL_APB1_GRP2_PERIPH_USART1); /**USART1 GPIO Configuration PA2 ------> USART1_TX */ GPIO_InitStruct.Pin = LL_GPIO_PIN_2; GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE; GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH; GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_OPENDRAIN; GPIO_InitStruct.Pull = LL_GPIO_PULL_UP; GPIO_InitStruct.Alternate = LL_GPIO_AF_1; LL_GPIO_Init(GPIOA, &GPIO_InitStruct); /* USART1 interrupt Init */ NVIC_SetPriority(USART1_IRQn, 1); NVIC_EnableIRQ(USART1_IRQn); USART_InitStruct.BaudRate = 38400; USART_InitStruct.DataWidth = LL_USART_DATAWIDTH_8B; USART_InitStruct.StopBits = LL_USART_STOPBITS_1; USART_InitStruct.Parity = LL_USART_PARITY_NONE; USART_InitStruct.TransferDirection = LL_USART_DIRECTION_TX_RX; >>>>>> USART_InitStruct.HardwareFlowControl = LL_USART_HWCONTROL_NONE; <<<<<< // THIS LINE WAS MISSING USART_InitStruct.OverSampling = LL_USART_OVERSAMPLING_16; LL_USART_Init(USART1, &USART_InitStruct); LL_USART_ConfigHalfDuplexMode(USART1); LL_USART_Enable(USART1); } </quote> originally the marked line was missing leaving the 'USART_InitStruct.HardwareFlowControl' entry uninitialized. this eventually led 'USARTx->CR3' to be modified through a WRITE_REG((REG), (((READ_REG(REG)) & (~(CLEARMASK))) | (SETMASK))) where CLEARMASK was (USART_CR3_RTSE | USART_CR3_CTSE) but SETMASK contained random stack-values and in my case the DMA bits had been asserted, swamping my I2C tx register because USART1 & I2C1 share the same DMA channel.... bugs of this kind are very hard to debug, so please evaluate all other XYZ_InitStruct for complete initialization for all combinations of MCU's. thanks for taking care of this issue regard ingops. an email reply bounced....
________________ Attachments : MSB2optima.ioc.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxQh&d=%2Fa%2F0X0000000axv%2FsokmivXZN4SePbpml4KfMpMbfXoJqwwjOuv2lXJhuEg&asPdf=falsepatch.txt.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxQc&d=%2Fa%2F0X0000000axu%2F4x16dl2nA.ZhmAqHynuxQFuwMYI3.CcqPDZUBQry7_c&asPdf=false2018-08-01 08:57 AM
Hi could you please attach the ioc and tell me which version of STMCubeMX are you using please?
Tested with the 4.26.1 and all is working good