STM32H743 serial

[David Binette]

Hi all

Trying to bring up a console on the STM32H7 either as UART serial with dev/console or later with USB CDC/ACM i get various unresolveds

"Architecture must provide up_putc() for this driver"

or missing definitions for

putc/putchar/puts/printf .. etc

I have a mandate to work on this device through my employer and can dedicate time and resources

to bring this port forward,  but i'm new to nuttx and the architecture.  I'd be more than happy to

 contribute effort on related tasks for this port to accomplish this.

Is there a path to serial console / nsh for this device at this time?

[patacongo]

Hi, David,

I am not sure of the current state of the port.  I brought this onto a branch as a contribution from the PX4 project.  It is most certainly unfinished.  I have have never even attempt to build the code yet so you are breaking new ground.

I did get an STM32H7 board recently and can work with you some.  Let me tinker with it and see if I can at least get it to compile.

Greg

[patacongo]

Hi, David,

I did get an STM32H7 board recently and can work with you some.  Let me tinker with it and see if I can at least get it to compile.

I did have to make a fix to get a clean compilation (but this was completely unrelated to the issues you say you are seeing).  I did this:

  git checkout stm32h7
  make distclean
  tools/configure.sh -c nucleo-h743zi/nsh
  make

and got this:

  ...
  make[2]: Entering directory '/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx/arch/arm/src/board'
  CC:  stm32_boot.c
  CC:  stm32_bringup.c
  AR:   stm32_boot.o stm32_bringup.o
  make[2]: Leaving directory '/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx/arch/arm/src/board'
  LD: nuttx
  make[1]: Leaving directory '/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx/arch/arm/src' 
  CP: nuttx.hex
  CP: nuttx.bin

Which are the final lines from an error-free build.

My understand is that the port is complete except for the RCC.  That still needs to be done.  That involves:

(1) Comparing arch/arm/src/stm32h7/chip/stm32_rcc.h with with the register and bit-field definitions in the STM32H7 user manual, and

(2) Updating arch/arm/src/stm32h7/stm32_rcc.c to use the correct clock configuration options.  This may require some comparison with STMicro sample clock configuration code to assure that the code is implemented correctly.

Greg

[David Binette]

Good compile with few warnings so..yes that works for me also, using Ubuntu Linux on windows 10 

 with the small change of tools/configure.sh -u nucleo-h743zi/nsh 

I'm wondering like UART support/baud etc are just a matter of configuration or not part of this port. 

make menuconfig isn'tg exposing settings for UART configuration, baudrates etc.

I'll look into the RCC and see if i can make something proper.

[patacongo]

I'm wondering like UART support/baud etc are just a matter of configuration or not part of this port. 

make menuconfig isn'tg exposing settings for UART configuration, baudrates etc.

You will find those settings under Drivers->Serial Support in the configuration menus.  Use '/' in mconf to find the location of any configuration setting.

[patacongo]

I'll look into the RCC and see if i can make something proper.

Other things missing in the H7 port should come over more or less directly from the F7 port.

[David Binette]

success is so close...

im hoping the drivers are there but just not being registered.

they UART/USART options aren't showing up in menuconfig

.config - Nuttx/ Configuration

 > Device Drivers > Serial Driver Support 

    Serial Driver Support 

                                      --- Serial Driver Support 

                                      [*]   16550 UART Chip support  --->

                                      [*]   Enable standard "upper-half" serial driver

                                      [*]   Serial TERMIOS support

                                      [*]   Pseudo-Terminal (PTY) suppport  --->

Pressing Z is can see many more (unavailable) options for uarts 

I hand modified nuttx/drivers/serial/Kconfig-usart and put in

config USART3_SERIALDRIVER

        bool

        default y

        select MCU_SERIAL

I chose USART3 because nucleo-144  routes it to the USB or a header depending on jumper

AFTER THAT change: menuconfig DID SHOW an offerring for USART3  but of course that didn't make the driver magically instantiate..

the resulting diagnostics elaborated that with

LD: nuttx

..../src/nuttx/staging/libdrivers.a(uart_16550.o): In function `u16550_serialin': ..../nuttx/drivers/serial/uart_16550.c:457: undefined reference to `uart_getreg'

..../src/nuttx/staging/libdrivers.a(uart_16550.o): In function `u16550_serialout': ..../nuttx/drivers/serial/uart_16550.c:467: undefined reference to `uart_putreg'

.../src/nuttx/staging/libdrivers.a(serial.o): In function `uart_irqwrite': ..../nuttx/drivers/serial/serial.c:380: undefined reference to `up_putc'

..../nuttx/drivers/serial/serial.c:385: undefined reference to `up_putc'

Makefile:204: recipe for target 'nuttx' failed

make[1]: *** [nuttx] Error 1

tools/Makefile.unix:422: recipe for target 'pass2' failed

make: *** [pass2] Error 2

I also tried enabling the DMA for the USART with no appreciable difference.

[Sebastien Lorquet]

hmm, not sure why the uart_16550 driver is enabled for a stm32?

Sebastien

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Binette]

@sebastion

the screen image of the menuconfig options had all items selected so that any available sub items would also be shown (if available)

(as opposed to the display of ALL items, even unavailable ones, that would be shown by the Z command)

The point is that there are currently NO uart/baudrate/config subitems available in the serial device driver listing for the STM32H743 

"All items selected" was not the mode i was trying to configure to, and as you noticed the 16550 driver is not appropriate to the nucleo-144 bnoard

so..  just for illustration

[Martin Schroeder]

How many of you are interested if I make an effort to add device tree
support to nuttx? Having any baud rate settings inside menuconfig is
absolutely not correct. All such configuration should be embedded
inside the device tree blob which the firmware reads during boot and
probes all drivers with project specific settings.

[Sebastien Lorquet]

I am not personally conviced that device tree (in the linux sense) is useful for
nuttx

that would mean that ALL drivers are always built and made available in EVERY
nuttx firmware !!

I think it makes no sense for an embedded OS that is always dedicated to run on
ONE board.

In linux it makes sense because the same linux image is expected to run on a
variety of machines, which is not required here.

But maybe I did not really understand what you mean?


And what is wrong with setting the boot baud rate in the config? You can change
it later programatically if you want.


Sebastien

[Martin Schroeder]

Sebastien, in a sense you are right about drivers but only in part.
There is a main issue with switching to data driven firmware
configuration approach (ie a device tree) in that it renders common
methods of getting rid of unused code not as effective anymore (still
usable though but with certain considerations). For example, using
-ffunction-sections and -fdata-sections along with --gc-sections will
not work as cleanly anymore as it does with completely preprocessor
driven configuration approach.

However, you are not correct when you say ALL drivers need to be
included. Instead of managing what gets included in the firmware at a
function level, one switches to doing it on driver level or file
level. The -ffunction-sections/-fdata-sections options will still work
as means of code cleanup, with the only difference that in order to
make the most of these options, one would need to make an extra effort
to ensure that no drivers that are not used are included in the build.
I'm using device tree today quite successfully with our FreeRTOS based
firmwares. What I have done is greatly simplify how the device tree is
used. I compile the device tree into a blob which gets written out as
a generated C file which contains a uint8_t array with the compiled
device tree blob. I then have macros defined which automatically
register drivers into a global linked list of all drivers that are
compiled into the firmware (similar to linux but just a lot more
simplified). Then during boot the user firmware calls
"probe_device_drivers()" with the device tree blob as argument.

There are numerous benefits that are very attractive with this
approach, at least in my current line of work:
- Device tree defines the init order of device drivers. Much better
than doing it in code.
- Device tree defines links between instances of devices. Ie if you
want your rfid driver to use main uart nr 1 or nr 2 as way of talking
to your reader, you set this in device tree and not in code. Also any
baud rate settings are defined in the device tree.
- Device tree allows all low level drivers to be the same for all
applications (ie "leds" driver doesn't need to change for
applications. Not even in the preprocessor sense where the written
code is the same but compiled code can have different meaning
depending on configuration it is compiled for. Nothing like that).
Device tree easily defines "references" from one device to another.
Simplest example is again led pins. All pinmux settings are defined in
one section containing only led pins and then leds section has a
reference to the pins. Application simply queries main led indicator
interface and manipulates abstract leds 1,2,3..etc. The mapping of
these leds to hardware is defined in the device tree. Very clean
approach that removes all need to modify the driver code for any
application.
- Device tree ensure that all settings are in one place, ie the device
tree file. This makes porting the code to a new board very
straightforward. Even compilation against linux targets is as simple
as supplying a new device tree which instead of defining hardware
settings, define tty settings and settings for various emulated
devices such as vcan instead of hardware can.
- Device tree defines a primitive form of devfs with same structure
for an array of applications. Ie the application can "open" devices
using paths in the device tree. For example,
serial_find("/serial/debug") returns an abstract serial interface that
points to the debug port. Which uart this actually ends up on is
configured in the device tree which corresponds to the board on which
the application will run.
- Device tree can be as small or big as your application desires. If
you only have a small number of devices to define then device tree
will be very small. Compiled binary device tree blob is quite
efficient storage as well. And the small amount of extra flash storage
that it takes up is a good price to pay for the flexibility it offers,
in my opinion.

I also heavily use c preprocessor in device tree. Some linux device
trees use preprocessor, others don't. I like using preprocessor
because it allows the device tree to include human readable bit
combinations that are easy to interpret. I took the preprocessor step
from linux and I just use it before compiling the device tree blob
with dtc and dumping it into hex string.

Libfdt is what I use for parsing the device tree.

Attached is a small example from an stm32 can driver I wrote which
reads it's settings from the device tree node that corresponds to the
device the driver is going to control. I'm very happy with how device
tree turned out for current project that I'm working on and will
probably never go back to the old approach of doing all of this using
ifdefs in code.

[patacongo]

Can we move this to a different, more appropriate thread?

[patacongo]

You will find those settings under Drivers->Serial Support in the configuration menus.  Use '/' in mconf to find the location of any configuration setting.

 

they UART/USART options aren't showing up in menuconfig

That is because the configuration options were never implemented.  Remember that this is a work in progress, not a mature port.  You will find many things missing.  This adds those configuration options:

commit ad150becb1eae75a26b53b162703486ef666b01e
Author: Gregory Nutt <gn...@nuttx.org>
Date:   Tue Jun 12 07:01:30 2018 -0600

    arch/arm/src/stm32h7:  Add configuration options to select an STM32H7 serial peripheral.  Not much use at the moment since there is no serial driver in place for the STM32H7.

But, of course, this will do you no good now because the STM32F7 serial driver was never ported to the STM32H7.  But, assuming that the peripherals are the same, it should be a drop in.