Hi Matteo,
Very nice! Great news!
Could you share what you did to fix the serial baud-rate? Are you using the
HSI instead of the external crystal?
BR,
Alan
On Fri, Jan 24, 2025 at 9:00 PM Matteo Golin wrote:
> Hello Alan,
>
> We managed to boot into NSH later this afternoon! Thanks again for
Amazing!!! Kudos!!!
On Sat, Jan 25, 2025 at 11:30 AM Matteo Golin
wrote:
> Hi Alan,
>
> The issue was the soldering job, no fault of our NuttX configuration. There
> was a short between a clock line and ground. The HSE now works totally
> fine, and modifying the clock registers was actually very
Hi Alan,
The issue was the soldering job, no fault of our NuttX configuration. There
was a short between a clock line and ground. The HSE now works totally
fine, and modifying the clock registers was actually very painless. They
were well commented and I only had to change a few multipliers to mak
On Sat, Jan 25, 2025 at 1:01 AM Matteo Golin wrote:
> We managed to boot into NSH later this afternoon! Thanks again for the help!
> (..)
> Thanks again for the help! I'll likely email here again later to show our
> flight computer once we confirm we can talk to the sensors and GPS.
Congratz Matt
Hello Alan,
We managed to boot into NSH later this afternoon! Thanks again for the help!
It appears after some grep searching that `board_autoled_on(LED_STARTED)`
is never called by any architecture startup code. Most boards seem to turn
on the start LED in the initialize function themselves. But
Hi Matteo,
Nice to know you are doing processes!
The diagnostic LEDs (CONFIG_ARCH_LEDS) is also "very board specific", the
Documentation highlights it here:
https://nuttx.apache.org/docs/latest/reference/os/led.html
Also, the board_autoled_on/off depends on how your LED is physically
connected o
Hello,
I've been able to get our board to boot with the help of this video on the
NuttX channel. At least, we can see LEDs. However I only get noise on the
USART console right now, so I am going to try running off of the HSI
instead of the HSE and see if anything changes. I think the shell is ther
Hi Matesz,
Yes, LWL is slow because it is working using a polling approach (AFAIK ARM
DAP has support for interruption, but it is not implemented yet).
The main purpose of the LWL is to be the initial console before the real
serial driver is not implemented yet.
I think J-Link is a nice tool and
> To be honest I didn't hear about this LWL (Lightweight Link) before,
what a great discovery, nsh directly over JTAG/SWD with no UART!!
Thank you Alan!! :-)
There is also RTT console support in NuttX, so you can use JLink debuggers
without any UART.
Also there are more powerful tools for Segger d
On Wed, Jan 22, 2025 at 3:26 PM Matteo Golin wrote:
> 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.
Modern debug probes usually pro
Thank you Alan, it appears I had a naive misunderstanding about changing
the clock value in the build :) My first time using STMs with NuttX, but
excited to see what we'll be capable of with it! I'll take a look into
calculating the registers properly and doing out out-of-tree build properly
as Seb
Hi Matteo,
So I think you found the issue: when you change the crystal you need to
find other divisor registers to fit the firmware frequencies, otherwise the
serial baud rate will be wrong.
Some people use the ST Cube to calculate these registers values
automatically (easy way), others do it man
Thank you as well Sebastien! We are planning to do an out-of-tree build, I
was just hoping to minorly modify an existing build locally to see about
booting NSH first. Perhaps it's more worthwhile to just start by doing it
the right way.
On Wed, Jan 22, 2025 at 10:57 AM Matteo Golin
wrote:
> Hell
Hello Alan,
Thank you for the insights, I will take a look at the video resource you
mentioned. Would the Weact image still not work if I modified the crystal
frequency value defined in the board source tree? We are using 24MHz, so I
changed the `BOARD_XTAL` to 24MHz from 25. Maybe my understandin
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 wit
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
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
On Wed, Jan 22, 2025 at 2:48 AM Matteo Golin 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
Hi Matteo
for my NUCLEO-H743ZI2 board I'm using the following script to flash the
SW using openocd, with few differences to your command:
simply launch:
flash_h7 nuttx
==
#!/usr/bin/sh
INSTALL_DIR=/usr
OPENOCD_DIR=$INSTALL_DIR/share/openocd/scripts
FLASH=$INSTALL_DIR/bin/openocd
For reference the command being used and its output is:
$ openocd -f interface/stlink.cfg -f target/stm32h7x.cfg -c "program
nuttx.bin 0x0800 verify reset exit"
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-sel
Hello everyone,
InSpace has manufactured our flight computer now, which is intended to run
NuttX. It is STM32H743 based (VIT6 version). We would like to flash one of
the existing STM32H743 builds from NuttX onto it to verify that it works
before proceeding to create our own board support package.
Thank you everyone for the responses, lots to consider.
I'll have some of our members look into reading the STM32 datasheets to check
for information about whether or not the
particular chip(s) we're interested will ship with DFU support or not. We're
trying to make the use of this board
as easy
Information on STM32F3 flashing example added:
https://github.com/apache/nuttx/pull/13698
Please provide other verified chips information so we can add, just
reply here with short description and I will add them for you :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Fri, Sep 27, 2024 at 4:17 PM wrote:
> On 2024-09-27 09:14:33, Nathan Hartman wrote:
> I don't like zephyr, but 'west flash' is a good thing they did. I proposed
> this in the past when there was a discussion about how to make nuttx more
> popular.
>
> You could create phony target 'make flash',
On Fri, Sep 27, 2024 at 3:16 PM Nathan Hartman wrote:
> Something along these lines should be added to Documentation.
I can add instructions from Michal to SMT32F3:
openocd -f interface/stlink.cfg -f target/stm32f3x.cfg -c 'program
nuttx.bin 0x0800'
I guess this should land in the top leve
On 2024-09-27 09:14:33, Nathan Hartman wrote:
> I just had an idea that it would be neat to write a utility, which could
> live under 'tools' (to be run on a developer machine) that would analyze
> the current configuration and automatically generate the correct openocd
> and gdb incantations. I ha
On Fri, Sep 27, 2024 at 2:24 AM wrote:
> On 2024-09-26 21:58:38, Matteo Golin wrote:
> > Hello all,
> > We figured we should check here first if anyone who had
> > experimented with STM32 chips knows offhand whether or not it's
> > possible to program over a USB interface, how to do it with the
>
On 2024-09-26 21:58:38, Matteo Golin wrote:
> Hello all,
> We figured we should check here first if anyone who had
> experimented with STM32 chips knows offhand whether or not it's
> possible to program over a USB interface, how to do it with the
> NuttX build environment, or if it requires additio
Hi Matteo
We are working with NUCLEO-F746ZG, NUCLEO-H745ZI-Q and NUCLEO-H743ZI2
boards for our control projects, using NuttX as RTOS.
The main result is the EMB-DAQ1board developed by Felipe Depine at Robots5:
https://www.robots5.com/electronics
Under NuttX we are able to use the following d
On 9/27/24 09:56, Karukkuvel Raj D wrote:
Hi Matteo,
If your device has USB support, you can upload the NuttX binary using
DFU mode.
To enter the DFU mode, you have to make the BOOT0 pin of MCU to the
high position and power cycle the board, then the MCU will enter DFU mode.
After that
Hello all,
InSpace is considering using an STM32 chip as the MCU for our flight computer
this year. We're building a custom board
around the chip for our specific application. We're considering the STM32
family because it's popular among rocketry
teams and is often used in flight computers.
In
31 matches
Mail list logo
