Hello,
The way we did it for our product, was to copy a canned board and modify
it for our hardware.
The resulting config can be out of tree, which is useful, even more so
when you do a custom project that is not sold and cannot be bought by
others.
Usually we have a separate git repo with a structure comparable to the
contents of a board in a subfolder:
theboard/board/src (with the stm32_boot.c et al sources)
theboard/board/include (with board.h and ioctl.h)
theboard/board/configs
theboard/board/configs/nsh
theboard/board/configs/nsh/defconfig (the minimal test config to check
the board)
theboard/board/configs/product
theboard/board/configs/product/defconfig (the default normal config)
theboard/apps
theboard/apps/nshlib etc etc etc
theboard/company/randomappweneed
Usually we also have theboard/tools and theboard/docs and
theboard/bootloader and more stuff we need.
We keep the nuttx repository at the same level as this repository so,
when we are in the main nuttx root, our board is at ../theboard
then we run:
tools/configure.sh -a ../theboard/apps ../theboard/board/configs/nsh
and a final make builds the binary we then post process (to insert the
bootloader and create an update image).
It is convenient to test the out-of-tree structure first, by copying all
the files from the known-good nucleo-h743zi2 directory, and check that
you are still able to build it, then make changes to fit your board.
Also remember that the out-of-tree board/src directory is also a place
where you can add custom drivers that nuttx will not want/need in their
sources.
Sebastien
On 22/01/2025 16:39, Alan C. Assis wrote:
Hi Matteo,
You cannot use the firmware binary from some random STM32H743 board on your
custom board, unless it is using the same clock frequency and same UART
console.
Looking at the board.h from weact-stm32h743 shows it is using a 25MHz
crystal, so I suppose you are using this same crystal value on your board,
correct?
The DFU on STM32 ROM doesn't require a special firmware, because after
flashed the FW you will restart the board and it will start at default
position (0x08000000).
Only DFUs that are loaded at the beginning of the Flash (like some old
Particle boards) require a different firmware that changes the FW inicial
loading offset.
What Tomek was saying is some STM32 boards have a programmer with virtual
console (normally you will see a ttyACM0 when you plug that board with a
builtin STLink on it), but for some reason it has not been used as default
console.
That is something we can improve, but there are some catches: some boards
like STM32F4Discovery have different board revisions with and without that
virtual console.
I think the best approach is to always create a Documentation in the
official web site explaining what is expected from each board config, this
way people can figure it out very easily.
When the NSH is not starting and we don't have serial console working, it
is possible to use LWL (a console over JTAG/SWD), I created a video
tutorial explaining how to use it:
https://www.youtube.com/watch?v=A4aCwoABGB8
I hope these suggestions help you to fix the issue. If you are still facing
issues, compile NuttX with debug symbols enabled and use OpenOCD + GDB to
see where it is stopping.
BR,
Alan
On Wed, Jan 22, 2025 at 11:26 AM Matteo Golin <matteo.go...@gmail.com>
wrote:
Thank you for the help so far. I have attached a second TTL cable to
attempt to read the UART1 NSH Shell, but I don't see anything appear. I did
change the default RX/TX pins though and there are maybe other settings I
need to change for them (like alternate function select). I will review the
MCU datasheet today to verify that the pins are being set up correctly.
I am not sure that trying an older release will resolve the issue, there's
likely something that I am doing wrong. This board is a completely custom
flight computer board so the UART1 not appearing is likely due to that.
There are a couple STM32H743 boards supported and I know at least one of
them was tested last release vote.
I figured I would be able to boot an NSH configuration of the Weact board
since it doesn't really rely on anything board specific except the clock
and which pins the UART are connected to. I was hoping I would be able to
get it working on our flight computer as a starting point and then develop
our own board support source tree from there.
I did not even realize it would be possible to get a shell over the debug
probe; that would be quite a useful feature for bringing up new boards! I
might read into that if I have success with the UART later.
On Wed, Jan 22, 2025, 4:02 AM Tomek CEDRO <to...@cedro.info> wrote:
On Wed, Jan 22, 2025 at 2:48 AM Matteo Golin <matteo.go...@gmail.com>
wrote:
I have attempted flashing the chip with an STLink using the openocd
commands suggested here, and the binaries can be flashed and verified
properly. I am attempting to flash the chip with the configuration for
the
weact-stm32h743:nsh since it is the most similar to our board. I cannot
seem to detect a shell on USART1 despite the binary flashing.
Hey there Matteo, I noticed that problem too on some boards, looks
like your flashing works fine, you probably need to double check if
console pins are set as you expect.. unfortunately not all STM32
targets have default configuration to provide nsh over stlink some
boards use different pins and you need to attach console over there
(additional usb2uart adapter). Some boards have that info in our
documentation that developer set defaults on purpose that way.
For me this is confusing and makes various boards testing harder. I
think all boards should have defaults set to provide nsh over debug
probe if one provides VCP/CDC so we use only one cable wherever
possible :-)
If this is not the case then you may want to step by step try
rebuilding older releases and compare results.. maybe some regression
was introduced in the meantime for that mcu / board?
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
