You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Nathan Hartman <ha...@gmail.com> on 2020/09/03 22:44:47 UTC
stm32 uart init bug?
I ran into a strange issue with serial init for STM32. If the UART is
already enabled/configured, our configuration does not seem to apply.
I discovered this because I used a bootloader to flash and run NuttX
on the arm/stm32/b-g474e-dpow1 board. The bootloader configs the UART
for 115200 baud 8E1.
This is how nsh looks if I type 'help' command:
nsh> [hp
hp usag hp [v] [md>]
d s mv s unam
[ p mb m sp umun
mp as mkd pn su uns
basnam dnam hp mkd pd s usp
bak dd hdump mh m m d
a h k mun md u
nsh> [
This is because Even Parity (and possibly other stale config) is still
in effect from the bootloader.
When I flash and run NuttX without the bootloader, the nsh prompt
works correctly with 115200 baud 8N1.
Has anyone seen this before?
Re: stm32 uart init bug?
Posted by David Sidrane <da...@nscdg.com>.
Some IP blocks need to be disabled to modify some registers.
David
On Thu, Sep 3, 2020, 3:45 PM Nathan Hartman <ha...@gmail.com>
wrote:
> I ran into a strange issue with serial init for STM32. If the UART is
> already enabled/configured, our configuration does not seem to apply.
>
> I discovered this because I used a bootloader to flash and run NuttX
> on the arm/stm32/b-g474e-dpow1 board. The bootloader configs the UART
> for 115200 baud 8E1.
>
> This is how nsh looks if I type 'help' command:
>
> nsh> [hp
> hp usag hp [v] [md>]
>
> d s mv s unam
> [ p mb m sp umun
> mp as mkd pn su uns
> basnam dnam hp mkd pd s usp
> bak dd hdump mh m m d
> a h k mun md u
> nsh> [
>
> This is because Even Parity (and possibly other stale config) is still
> in effect from the bootloader.
>
> When I flash and run NuttX without the bootloader, the nsh prompt
> works correctly with 115200 baud 8N1.
>
> Has anyone seen this before?
>
Re: stm32 uart init bug?
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Sep 4, 2020 at 11:30 AM David Sidrane <Da...@nscdg.com> wrote:
> 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.
I just noticed your email, *after* creating PR-1719 :-/
I didn't use the RCC to force a complete peripheral reset on the
USART. I turned off the USART_CR1_UE bit before beginning
configuration. That solves the issue I had where the broken
bootloader's settings "stuck" after booting NuttX.
If you could, please take a look (I requested your review). If you
still think I should do a complete RCC peripheral reset, let me
know...
Thanks for your input,
Nathan
RE: stm32 uart init bug?
Posted by David Sidrane <Da...@nscdg.com>.
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.nathan@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 <sp...@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
Re: stm32 uart init bug?
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Sep 4, 2020 at 9:46 AM Gregory Nutt <sp...@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
Re: stm32 uart init bug?
Posted by Gregory Nutt <sp...@gmail.com>.
> 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.
RE: stm32 uart init bug?
Posted by David Sidrane <Da...@nscdg.com>.
Nathan,
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.
David
-----Original Message-----
From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
Sent: Thursday, September 03, 2020 7:08 PM
To: dev@nuttx.apache.org
Subject: Re: stm32 uart init bug?
On Thu, Sep 3, 2020 at 7:38 PM Gregory Nutt <sp...@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
Re: stm32 uart init bug?
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Sep 3, 2020 at 7:38 PM Gregory Nutt <sp...@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
Re: stm32 uart init bug?
Posted by Gregory Nutt <sp...@gmail.com>.
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)*/
On 9/3/2020 4:44 PM, Nathan Hartman wrote:
> I ran into a strange issue with serial init for STM32. If the UART is
> already enabled/configured, our configuration does not seem to apply.
>
> I discovered this because I used a bootloader to flash and run NuttX
> on the arm/stm32/b-g474e-dpow1 board. The bootloader configs the UART
> for 115200 baud 8E1.
>
> This is how nsh looks if I type 'help' command:
>
> nsh> [hp
> hp usag hp [v] [md>]
>
> d s mv s unam
> [ p mb m sp umun
> mp as mkd pn su uns
> basnam dnam hp mkd pd s usp
> bak dd hdump mh m m d
> a h k mun md u
> nsh> [
>
> This is because Even Parity (and possibly other stale config) is still
> in effect from the bootloader.
>
> When I flash and run NuttX without the bootloader, the nsh prompt
> works correctly with 115200 baud 8N1.
>
> Has anyone seen this before?