Closed strongly-typed closed 7 years ago
This would be done here at the very beginning of the startup script. It'll likely be split into two functions in the future, but don't worry about that for now.
What assumptions does xpcc make about state of the processor?
Power-on reset, which can differ significantly from a debugger reset or when the device resets itself (like DFU). Not sure what to do about that, didn't come up until now.
Though technically this is also an issue with the ClockControl
Implementation that does not correctly configure this bit. This could be solved with #39.
Hi guys,
while exploring STM32F7 support, we (@daniel-k) discovered that the DFU bootloader leaves the processor in a non-reset configuration, e.g. USART1 is clocked from PCLK2, instead of ABP2. See
RCC->DCKCFGR2
.This leads to incorrect baud rates when using xpcc.
What is the best place to reset
RCC->DCKCFGR2
to reset defaults? Is it either in the clock config code, or like xpcc_gpio_enable() in startup.c?Meta: There may be other configurations which differ from reset-configuration when using the DFU. What assumptions does xpcc make about state of the processor?
Any suggestions appreciated.