Hi @lgacnik97 On STM32U5xx serie, there's no WakeupCallback (no WUF/WUS settings). So UART_HandleTypeDef type definition is correct.On the other hand, the value HAL_UART_WAKEUP_CB_ID could then be removed from HAL_UART_CallbackIDTypeDef enumeration, ...
Hi @StefanInfi Indeed, as mentioned by @waclawek.jan, handling a 1Mbaud with a 16Mhz clock source is the limit. To relax this on RX, could you try to initialize your USART2 with OverSampling_8 configuration :huart2.Init.OverSampling = UART_OVERSAMPLI...
Hi @himani Maybe an alternative for you could be to use a STM32H562 or 563 or 573 (instead of STM32H503).STM32H56x/57x embeds a UCPD peripheral able to manage USB Type-C/USB Power Delivery connections.You could also find in STM32Cube H5 package avail...
Hi @_alaBaster I think ReceiveToIdle API should be available in latest STM32L0 HAL drivers version (please check in stm32l0xx_uart_ex.c). If not, maybe you could have a look in latest version of STM32L0 HAL drivers available on github here .API prot...
Hi @Marosh In my understanding, you could have your definition of SNK PDOs covering various voltages and power. At the end, whatever those PDOs, decision about which SRC PDO to choose to build the REQUEST message is a SNK decision.Entry point of this...