On Thu, Sep 3, 2020 at 7:38 PM Gregory Nutt <spudan...@gmail.com> wrote:
> Perhaps: > > Bit 10PCE: Parity control enableThis bit selects the hardware parity > control (generation and detection). When the parity control is enabled, > the computedparity is inserted at the MSB position (9th bit if M=1; 8th > bit if M=0) and the parity is checked on the received data. This bit is > set and cleared by software. Once it is set, PCE is active after the > current byte (in reception and in transmission).0: Parity control > disabled1: Parity control enabled/*This bitfield can only be writte*//*n > when the USART is disabled (U*//*E=0).*/ > > Bit 9PS: Parity selectionThis bit selects the odd or even parity when > theparity generation/detection is enabled (PCE bit set). It is set and > cleared by software.The parity is selected after the current byte.0: > Even parity1: Odd parityT/*his bitfield can only be writte*//*n when the > USART is disabled (U*//*E=0)*/ Yes, that looks like the culprit, in combination with the bootloader not being well behaved. I think we should ensure the USART is disabled before attempting to configure it. This probably was never caught before because it doesn't manifest as long as NuttX starts out of reset, or people who used serial bootloaders were using the more common 8N1 setting, or they were using a more well-behaved bootloader. In any case, I think it's best to ensure that we can configure the UART successfully no matter the initial conditions. I'll try to get a PR tomorrow. It's been a long day. Separately, I need to implement a custom bootloader for various reasons, so I'll make sure it performs a complete teardown before launching NuttX. :-) Thanks for your help, Nathan
