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
On Sun, Apr 28, 2024 at 1:45 AM M. Edward (Ed) Borasky <
zn...@algocompsynth.com> wrote:
> I've just run across NuttX, and I think it's a good fit for my project.
> What I'm trying to do is develop some computer music applications on
> microcontrollers. I'm mostly interested in the Raspberry Pi Pi
I've just run across NuttX, and I think it's a good fit for my project. What
I'm trying to do is develop some computer music applications on
microcontrollers. I'm mostly interested in the Raspberry Pi Pico, but I also
have some ESP32 S3, ESP 32 C3/C6, and Teensy 4.1 boards aand would like the
a
hardware dependencies. I even can
> mount master's file system and run programs from it on the remote
> node, as the remote node's capability is superset of that of the master
> node.
>
>
>
>
>
> Here I have some questions regarding RPTUN:
>
>
>
>
>
&g
> Using the latest version I got some problems:
> > https://github.com/apache/nuttx/issues/8767
> >
> > I think it should be fine using the stable release since I have no idea
> > what is going wrong using master.
> >
> > As for my questions:
> > I cou
atest version I got some problems:
> https://github.com/apache/nuttx/issues/8767
>
> I think it should be fine using the stable release since I have no idea
> what is going wrong using master.
>
> As for my questions:
> I could not find a lot of information about the status o
got some problems:
https://github.com/apache/nuttx/issues/8767
I think it should be fine using the stable release since I have no idea
what is going wrong using master.
As for my questions:
I could not find a lot of information about the status of the bluetooth for
NuttX, only articles on running
While looking into the mcp2515 driver I noticed something unexpected.
In mcp2515_instantiate() it does the follofing:
SPI_SETFREQUENCY(config->spi, CONFIG_MCP2515_SPI_SCK_FREQUENCY);
SPI_SETMODE(config->spi, MCP2515_SPI_MODE);
SPI_SETBITS(config->spi, 8);
SPI_HWFEATURES(config->spi, 0);
I
Hi Briann,
The main idea of NuttX RTOS is to have a POSIX and in some way a Linux-like
RTOS that runs on low/mid-end microcontrollers, like STM32, ESP32, etc.
You also can run NuttX on high-end processors like Freescale/NXP iMX6 and
others. Then in theory you can port Java Virtual Machine and eve
Can Apache NuttX run Apache Programs within NuttX? Apps such as Flink or
Storm?
r MTD device that span all the
small ones.
This is a kind of raid0 for MTD devices.
I have questions about the API. Basically there are two choices:
-have an empty initialiser (mtd_agg_init()) that return the larger
device, and a function mtd_agg_adddev(child) to grow the device
-have
cked) and the result is one larger MTD device that span all the
small ones.
This is a kind of raid0 for MTD devices.
I have questions about the API. Basically there are two choices:
-have an empty initialiser (mtd_agg_init()) that return the larger
device, and a function mtd_agg_adddev(chi
span all the small
ones.
This is a kind of raid0 for MTD devices.
I have questions about the API. Basically there are two choices:
-have an empty initialiser (mtd_agg_init()) that return the larger
device, and a function mtd_agg_adddev(child) to grow the device
-have an initializer that takes
On Fri, Jul 31, 2020 at 1:42 PM Gregory Nutt wrote:
>
> > Before we change the coding standard, I suggest that we get more
> > feedback from the dev community.
> >
> > My opinion: If a loop does not require a body, I suggest to use
> > braces, rather than a semicolon, because it is less prone to
Before we change the coding standard, I suggest that we get more
feedback from the dev community.
My opinion: If a loop does not require a body, I suggest to use
braces, rather than a semicolon, because it is less prone to
programmer error. ...
I should not be so opposed to coding standard ch
As a conclusion for me:
If you don't want to force braces, the macos/sim build test needs to be fixed.
Importantly: It's not a style test that is failing, it's a build test.
Nevertheless I will change the code in my PR to use braces, because it seems to
be the preferred way (at least by Greg and N
My opinion: If a loop does not require a body, I suggest to use
braces, rather than a semicolon, because it is less prone to
programmer error. I would be okay with either:
while (condition)
{
}
or
while (condition) {}
And of the two, I think the second one expresses the intent best.
On Fri, Jul 31, 2020 at 10:55 AM Gregory Nutt wrote:
> > Hmmm... I don't agree.
> >
> > The Coding Standard encourages empty "while loops":
> > https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#while
> > Why should this not applicable for "for loops"? I think there are many
> > al
Hmmm... I don't agree.
The Coding Standard encourages empty "while loops":
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#while
Why should this not applicable for "for loops"? I think there are many already
in the tree.
Actually, I think that is an error in the coding docum
ild / macOS (sim)" complaining?
Johannes
> -Original Message-
> From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
> Sent: Friday, July 31, 2020 4:15 PM
> To: dev@nuttx.apache.org
> Subject: [!!Mass Mail]Re: Some questions related PR#1478
>
> On Fri, Jul 31, 2020 a
On Fri, Jul 31, 2020 at 9:46 AM Schock, Johannes - NIVUS GmbH <
johannes.sch...@nivus.com> wrote:
> Hello,
> I have two questions related PR#1478 (
> https://github.com/apache/incubator-nuttx/pull/1478):
>
> 1. I think there's a configuration error with "Build / m
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> fsync on any open file descriptor will flush the file system since data
> is only buffered for for metadata and one file at a time.
This explains why my problem seems gone after I introduced a fsync on the file
in my test case.
I will have anoth
2. Is there a way to flush a fat file system? Because I think the unexpected
behaviour I've seen was related to debugging and fat cache flush.
I tried to use fsync on the folder (which was proposed in a linux related
discussion), but open on a folder returns errno 21 (is a directory).
fsync o
Hello,
I have two questions related PR#1478
(https://github.com/apache/incubator-nuttx/pull/1478):
1. I think there's a configuration error with "Build / macOS (sim)" since it is
using -Wempty-body, or is this intentional?
It gives errors for
for (namelen = 0; dirinfo->
Yes! Should I do the same workaround as Greg mentions there, namely to
add an additional "Included Files" section for the conditional
includes?
We have just been ignoring this style error in previous PRs.
If you want someone to ignore and nxstyle complaint, I think the the
etiquette is to a
On Mon, Apr 27, 2020 at 1:29 PM Abdelatif Guettouche
wrote:
> Here are the supported sections:
> https://github.com/apache/incubator-nuttx/blob/master/tools/nxstyle.c#L131
> (There is an "s" too many in what I wrote above, it's "Public Function
> Prototypes")
Thanks. More below:
> On Mon, Apr 27
Here are the supported sections:
https://github.com/apache/incubator-nuttx/blob/master/tools/nxstyle.c#L131
(There is an "s" too many in what I wrote above, it's "Public Function
Prototypes")
On Mon, Apr 27, 2020 at 7:20 PM Abdelatif Guettouche
wrote:
>
> > (1) arch/arm/include/stm32/stm32f40xxx_
> (1) arch/arm/include/stm32/stm32f40xxx_irq.h:361:3: error: Invalid
> section for this file type
For a header file the section "Public Functions" should not exist,
it's actually "Public Functions Prototypes"
> (2) arch/arm/include/stm32/irq.h:81:3: warning: #include outside of
> 'Included Files'
I am not sure what to do about the following nxstyle complaints:
(1) arch/arm/include/stm32/stm32f40xxx_irq.h:361:3: error: Invalid
section for this file type
Should I just remove the section? What to do with the unused
__ASSEMBLY__, __cplusplus, and extern "C" stuff?
(2) arch/arm/include/stm32/
Hi,
I'm trying to port the imxrt SD Card driver (imxrt_usdhc.c) to the
sama5d27. Both chips appear to use similar Cadence IP blocks... the
registers appear to be almost identical. I know the SDMMC peripheral and
the SD Card both work since I can boot from it using U-Boot on the
SAMA5D2-XULT board.
what's the status of CONFIG_BUILD_KERNEL?
it seems only sama5 has the necessary up_ functions. is this right?
is there a way to run on emulators like qemu?
I have not used the kernel build in some time. It has been used in
products in the past so it is complete and usable but has some
limi
hi,
what's the status of CONFIG_BUILD_KERNEL?
it seems only sama5 has the necessary up_ functions. is this right?
is there a way to run on emulators like qemu?
thank you
62 matches
Mail list logo
