I was not suggesting the fix should be in the boot loader, I was just commenting on what the right way to do a boot loader.
I am sure the F4/F7 serial drivers deal with the PE bits. It has many test cases in the RC lib of PX4, it the low level stuff that most likely does not work correctly And should be fixed. Consider using the RCC xxxx peripheral reset register to get to ground state for the UxART then it should be very straight forward. RESET STATE + config chosen. David -----Original Message----- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Friday, September 04, 2020 7:42 AM To: dev@nuttx.apache.org Subject: Re: stm32 uart init bug? On Fri, Sep 4, 2020 at 9:46 AM Gregory Nutt <spudan...@gmail.com> wrote: > > > Sometimes the best results (on small systems) are obtained if boot > > loader > > leaves the CPU as it found it out of reset. > > > > If you think in terms of an OOD life cycle: The "Destructor" for each > block > > reset the HW to the reset state. > > > > With this approach, the SoC out of reset, and executing at __start from > the > > bootloader are 100% documented by the information the data sheet and the > > reference manual. > You would still need to disable the UART in the STM32 code in order to > re-configure partity (and maybe other planners). So the solution is in > stm32_lowputc.c, not in the bootloader. > Agreed. Fixing that there will prevent others from encountering similar problems, regardless whether there's a bootloader involved or not. To David's point, I agree the bootloader should be well behaved and restore initial conditions before it exits. I intend to fix both for correctness. PR coming soon for stm32_lowputc.c. Nathan
