You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Matteo Golin <ma...@gmail.com> on 2024/09/27 01:58:38 UTC
Questions about STM32 support/programming
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 the MCU listing the two most well documented variants are the STM32F7 and F4 it seems, but we're having trouble
deciphering how we would flash the MCU with NuttX from the instructions for the individual boards and on the main MCU
page.
Example for the STM32F7, this page doesn't mention the programming interface/process:
https://nuttx.apache.org/docs/latest/platforms/arm/stm32f7/index.html
Looking at an individual board with an F7 chip, the page for the Nucleo doesn't mention it either:
https://nuttx.apache.org/docs/latest/platforms/arm/stm32f7/boards/nucleo-f722/index.html
The page for the board says it can only be programmed using ST-Link. We've done some research and found that most STM32s
were using the ST-Link programmer for programming, but it is also possible to load programs over USB using a USB
bootloader on some chips.
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 additional
hardware.
I recalled seeing a porting livestream on the NuttX channel and checked out the board with an STM32F4 by Lucas Zampar,
and it appears to have serial wire debug and JTAG programming interfaces. I see there is also a USB interface but I'm
not sure if programming over it is possible:
https://github.com/lucaszampar/NuttX_STM32F4_RS485_DevBoard/blob/main/PDF/NuttX_STM32F4_RS485.pdf
If so, it would be great to know how that is achieved! Many resources mention a USB bootloader but I'm not sure if it's
first required to upload the bootloader over SWD before being able to use it. I'm also not sure how this looks
specifically with NuttX's build system. It's highly possible I am just missing seeing some relevant information in the
NuttX docs but I can't seem to find what I'm looking for.
Thanks,
Matteo
Re: Questions about STM32 support/programming
Posted by Roberto Bucher <bu...@gmail.com>.
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 devices on the board:
* Digital input and output
* ADC inputs
* PWM outputs
* Incremental encoders
* CAN Bus
* Network
Under Linux, in order to program the boards trough the USB bus we are
working with OPENOCD and some simple scripts. For the F7 boards the
scripts is:
/----------------------------------------------------
/
/#!/usr/bin/sh
INSTALL_DIR=/usr
OPENOCD_DIR=$INSTALL_DIR/share/openocd/scripts
FLASH=$INSTALL_DIR/bin/openocd
FLASH_FLAGS="-f $OPENOCD_DIR/interface/stlink.cfg -f
$OPENOCD_DIR/target/stm32f7x.cfg"
$FLASH $FLASH_FLAGS -c "program $1 verify reset exit"/
/------------------------------------------------
/
where "$1" is the name of the NuttX generated file after compiling and
build.
There is also a project at the Florida Institute of Technology, with
the aim to use pysimCoder to control the flight software of a CubeSat,
using a F7 board:
https://arc.aiaa.org/doi/10.2514/6.2024-1663
Best regards
Roberto
On 9/27/24 3:58 AM, Matteo Golin wrote:
> Hello all,
>
> InSpace is considering using an STM32 chip as the MCU for our flight computer this year. We're building a custom boardF746ZG
> 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 the MCU listing the two most well documented variants are the STM32F7 and F4 it seems, but we're having trouble
> deciphering how we would flash the MCU with NuttX from the instructions for the individual boards and on the main MCU
> page.
>
> Example for the STM32F7, this page doesn't mention the programming interface/process:
> https://nuttx.apache.org/docs/latest/platforms/arm/stm32f7/index.html
>
> Looking at an individual board with an F7 chip, the page for the Nucleo doesn't mention it either:
> https://nuttx.apache.org/docs/latest/platforms/arm/stm32f7/boards/nucleo-f722/index.html
>
> The page for the board says it can only be programmed using ST-Link. We've done some research and found that most STM32s
> were using the ST-Link programmer for programming, but it is also possible to load programs over USB using a USB
> bootloader on some chips.
>
> 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 additional
> hardware.
>
> I recalled seeing a porting livestream on the NuttX channel and checked out the board with an STM32F4 by Lucas Zampar,
> and it appears to have serial wire debug and JTAG programming interfaces. I see there is also a USB interface but I'm
> not sure if programming over it is possible:
> https://github.com/lucaszampar/NuttX_STM32F4_RS485_DevBoard/blob/main/PDF/NuttX_STM32F4_RS485.pdf
>
> If so, it would be great to know how that is achieved! Many resources mention a USB bootloader but I'm not sure if it's
> first required to upload the bootloader over SWD before being able to use it. I'm also not sure how this looks
> specifically with NuttX's build system. It's highly possible I am just missing seeing some relevant information in the
> NuttX docs but I can't seem to find what I'm looking for.
>
> Thanks,
>
> Matteo
Re: Questions about STM32 support/programming
Posted by Tomek CEDRO <to...@cedro.info>.
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
Re: Questions about STM32 support/programming
Posted by Tomek CEDRO <to...@cedro.info>.
On Fri, Sep 27, 2024 at 3:16 PM Nathan Hartman <ha...@gmail.com> 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 0x08000000'
I guess this should land in the top level Supported Platforms / ARM /
SMT32F right?
If you have info on other chips please reply and I will update the
documentation too :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Questions about STM32 support/programming
Posted by Tomek CEDRO <to...@cedro.info>.
On Sat, Jan 25, 2025 at 1:01 AM Matteo Golin <ma...@gmail.com> 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 Matteo! Fingers crossed! Have fun!! :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Questions about STM32 support/programming
Posted by "Alan C. Assis" <ac...@gmail.com>.
Amazing!!! Kudos!!!
On Sat, Jan 25, 2025 at 11:30 AM Matteo Golin <ma...@gmail.com>
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 painless. They
> were well commented and I only had to change a few multipliers to make the
> frequencies line up.
>
> On Sat, Jan 25, 2025, 9:25 AM Alan C. Assis <ac...@gmail.com> wrote:
>
> > 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 <ma...@gmail.com>
> > wrote:
> >
> > > 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, panic and
> > > assertion and etc. calls are made, so it's good to know it's not a
> > problem
> > > with our LED code. I was able to turn them all on from the initialize
> > > function as well.
> > >
> > > 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.
> > >
> > > Matteo
> > >
> > > On Fri, Jan 24, 2025, 6:25 PM Alan C. Assis <ac...@gmail.com> wrote:
> > >
> > > > 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 on your board: common cathode / common anode.
> > > >
> > > > You need to keep it in mind to configure your board LED for
> diagnostics
> > > > purposes correctly.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Fri, Jan 24, 2025 at 6:15 PM Matteo Golin <matteo.golin@gmail.com
> >
> > > > wrote:
> > > >
> > > > > 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
> > > > there,
> > > > > just at the wrong speed. The boot time is quite slow so I think
> > > something
> > > > > may be wrong with our HSE.
> > > > >
> > > > > I have one question, which is that I'm noticing that the autoleds
> > does
> > > > not
> > > > > seem to be working properly. I found that the `board_autoled_on`
> > > function
> > > > > never seems to be called with LED_STARTED. I can turn on the LEDs
> if
> > I
> > > > set
> > > > > them high in the `board_autoled_initialize` function though. In the
> > > > > menuconfig options I saw that I can also enable
> > > > > `CONFIG_ARCH_LEDS_CPU_ACTIVITY`. Is this needed to have
> > > > > `board_autoled_on(LED_STARTED)` to occur?
> > > > >
> > > > > Thanks again for all your help!
> > > > > Matteo
> > > > >
> > > > > On Thu, Jan 23, 2025 at 11:31 AM Alan C. Assis <ac...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > 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 I have it too. But it is always
> > > > better
> > > > > to
> > > > > > use an open source solution when possible :-)
> > > > > >
> > > > > > BR,
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > > On Thu, Jan 23, 2025 at 5:46 AM raiden00pl <raiden00pl@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > > 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 debuggers in
> NuttX,
> > > > like
> > > > > > > SystemView.
> > > > > > >
> > > > > > > Last time I tested LWL it was terribly slow and heavily loaded
> > the
> > > > CPU
> > > > > -
> > > > > > > incomparably worse than RTT.
> > > > > > >
> > > > > > > Personally I recommend converting STLINK to JLINK if possible
> > with
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
> > > > > > > or even investing in a dedicated tool from Segger. It's really
> > > money
> > > > > > worth
> > > > > > > investment.
> > > > > > >
> > > > > > > śr., 22 sty 2025 o 22:45 Tomek CEDRO <to...@cedro.info>
> > > napisał(a):
> > > > > > >
> > > > > > > > On Wed, Jan 22, 2025 at 3:26 PM Matteo Golin <
> > > > matteo.golin@gmail.com
> > > > > >
> > > > > > > > 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 provide JTAG/SWD interface for
> > debug
> > > > (USB
> > > > > > > > HID), UART console (USB CDC), and filesystem storage for
> > > > > drag-and-drop
> > > > > > > > firmware flashing (USB MSC) over single USB connection. Even
> > > "dumb"
> > > > > > > > FT2232 like probes have two channels one for JTAG/SWD and
> > another
> > > > for
> > > > > > > > UART console :-)
> > > > > > > >
> > > > > > > > Most STLinks provide all 3 functionalities, except the old
> ones
> > > > with
> > > > > > > > small MCU that provides onboard debug only. You can even use
> > most
> > > > > > > > STM32 devkits as the debug probe (jumpers configurable).
> Latest
> > > > > > > > devkits use more powerful MCU for the onboard debug probe
> than
> > > the
> > > > > > > > target MCU few years back. There is a windoze based utility
> > from
> > > > STM
> > > > > > > > that allows you to upgrade firmware and view / configure
> > feature
> > > of
> > > > > > > > various STLink debug probes including those installed on
> > > devkits..
> > > > it
> > > > > > > > sometimes solves strange problems too :-)
> > > > > > > >
> > > > > > > > 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!! :-)
> > > > > > > >
> > > > > > > > https://www.youtube.com/watch?v=A4aCwoABGB8
> > > > > > > >
> > > > > > > > --
> > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Questions about STM32 support/programming
Posted by Matteo Golin <ma...@gmail.com>.
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 make the
frequencies line up.
On Sat, Jan 25, 2025, 9:25 AM Alan C. Assis <ac...@gmail.com> wrote:
> 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 <ma...@gmail.com>
> wrote:
>
> > 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, panic and
> > assertion and etc. calls are made, so it's good to know it's not a
> problem
> > with our LED code. I was able to turn them all on from the initialize
> > function as well.
> >
> > 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.
> >
> > Matteo
> >
> > On Fri, Jan 24, 2025, 6:25 PM Alan C. Assis <ac...@gmail.com> wrote:
> >
> > > 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 on your board: common cathode / common anode.
> > >
> > > You need to keep it in mind to configure your board LED for diagnostics
> > > purposes correctly.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Fri, Jan 24, 2025 at 6:15 PM Matteo Golin <ma...@gmail.com>
> > > wrote:
> > >
> > > > 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
> > > there,
> > > > just at the wrong speed. The boot time is quite slow so I think
> > something
> > > > may be wrong with our HSE.
> > > >
> > > > I have one question, which is that I'm noticing that the autoleds
> does
> > > not
> > > > seem to be working properly. I found that the `board_autoled_on`
> > function
> > > > never seems to be called with LED_STARTED. I can turn on the LEDs if
> I
> > > set
> > > > them high in the `board_autoled_initialize` function though. In the
> > > > menuconfig options I saw that I can also enable
> > > > `CONFIG_ARCH_LEDS_CPU_ACTIVITY`. Is this needed to have
> > > > `board_autoled_on(LED_STARTED)` to occur?
> > > >
> > > > Thanks again for all your help!
> > > > Matteo
> > > >
> > > > On Thu, Jan 23, 2025 at 11:31 AM Alan C. Assis <ac...@gmail.com>
> > > wrote:
> > > >
> > > > > 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 I have it too. But it is always
> > > better
> > > > to
> > > > > use an open source solution when possible :-)
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > > On Thu, Jan 23, 2025 at 5:46 AM raiden00pl <ra...@gmail.com>
> > > wrote:
> > > > >
> > > > > > > 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 debuggers in NuttX,
> > > like
> > > > > > SystemView.
> > > > > >
> > > > > > Last time I tested LWL it was terribly slow and heavily loaded
> the
> > > CPU
> > > > -
> > > > > > incomparably worse than RTT.
> > > > > >
> > > > > > Personally I recommend converting STLINK to JLINK if possible
> with
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
> > > > > > or even investing in a dedicated tool from Segger. It's really
> > money
> > > > > worth
> > > > > > investment.
> > > > > >
> > > > > > śr., 22 sty 2025 o 22:45 Tomek CEDRO <to...@cedro.info>
> > napisał(a):
> > > > > >
> > > > > > > On Wed, Jan 22, 2025 at 3:26 PM Matteo Golin <
> > > matteo.golin@gmail.com
> > > > >
> > > > > > > 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 provide JTAG/SWD interface for
> debug
> > > (USB
> > > > > > > HID), UART console (USB CDC), and filesystem storage for
> > > > drag-and-drop
> > > > > > > firmware flashing (USB MSC) over single USB connection. Even
> > "dumb"
> > > > > > > FT2232 like probes have two channels one for JTAG/SWD and
> another
> > > for
> > > > > > > UART console :-)
> > > > > > >
> > > > > > > Most STLinks provide all 3 functionalities, except the old ones
> > > with
> > > > > > > small MCU that provides onboard debug only. You can even use
> most
> > > > > > > STM32 devkits as the debug probe (jumpers configurable). Latest
> > > > > > > devkits use more powerful MCU for the onboard debug probe than
> > the
> > > > > > > target MCU few years back. There is a windoze based utility
> from
> > > STM
> > > > > > > that allows you to upgrade firmware and view / configure
> feature
> > of
> > > > > > > various STLink debug probes including those installed on
> > devkits..
> > > it
> > > > > > > sometimes solves strange problems too :-)
> > > > > > >
> > > > > > > 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!! :-)
> > > > > > >
> > > > > > > https://www.youtube.com/watch?v=A4aCwoABGB8
> > > > > > >
> > > > > > > --
> > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Questions about STM32 support/programming
Posted by "Alan C. Assis" <ac...@gmail.com>.
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 <ma...@gmail.com> wrote:
> 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, panic and
> assertion and etc. calls are made, so it's good to know it's not a problem
> with our LED code. I was able to turn them all on from the initialize
> function as well.
>
> 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.
>
> Matteo
>
> On Fri, Jan 24, 2025, 6:25 PM Alan C. Assis <ac...@gmail.com> wrote:
>
> > 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 on your board: common cathode / common anode.
> >
> > You need to keep it in mind to configure your board LED for diagnostics
> > purposes correctly.
> >
> > BR,
> >
> > Alan
> >
> > On Fri, Jan 24, 2025 at 6:15 PM Matteo Golin <ma...@gmail.com>
> > wrote:
> >
> > > 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
> > there,
> > > just at the wrong speed. The boot time is quite slow so I think
> something
> > > may be wrong with our HSE.
> > >
> > > I have one question, which is that I'm noticing that the autoleds does
> > not
> > > seem to be working properly. I found that the `board_autoled_on`
> function
> > > never seems to be called with LED_STARTED. I can turn on the LEDs if I
> > set
> > > them high in the `board_autoled_initialize` function though. In the
> > > menuconfig options I saw that I can also enable
> > > `CONFIG_ARCH_LEDS_CPU_ACTIVITY`. Is this needed to have
> > > `board_autoled_on(LED_STARTED)` to occur?
> > >
> > > Thanks again for all your help!
> > > Matteo
> > >
> > > On Thu, Jan 23, 2025 at 11:31 AM Alan C. Assis <ac...@gmail.com>
> > wrote:
> > >
> > > > 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 I have it too. But it is always
> > better
> > > to
> > > > use an open source solution when possible :-)
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Thu, Jan 23, 2025 at 5:46 AM raiden00pl <ra...@gmail.com>
> > wrote:
> > > >
> > > > > > 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 debuggers in NuttX,
> > like
> > > > > SystemView.
> > > > >
> > > > > Last time I tested LWL it was terribly slow and heavily loaded the
> > CPU
> > > -
> > > > > incomparably worse than RTT.
> > > > >
> > > > > Personally I recommend converting STLINK to JLINK if possible with
> > > > >
> > > > >
> > > >
> > >
> >
> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
> > > > > or even investing in a dedicated tool from Segger. It's really
> money
> > > > worth
> > > > > investment.
> > > > >
> > > > > śr., 22 sty 2025 o 22:45 Tomek CEDRO <to...@cedro.info>
> napisał(a):
> > > > >
> > > > > > On Wed, Jan 22, 2025 at 3:26 PM Matteo Golin <
> > matteo.golin@gmail.com
> > > >
> > > > > > 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 provide JTAG/SWD interface for debug
> > (USB
> > > > > > HID), UART console (USB CDC), and filesystem storage for
> > > drag-and-drop
> > > > > > firmware flashing (USB MSC) over single USB connection. Even
> "dumb"
> > > > > > FT2232 like probes have two channels one for JTAG/SWD and another
> > for
> > > > > > UART console :-)
> > > > > >
> > > > > > Most STLinks provide all 3 functionalities, except the old ones
> > with
> > > > > > small MCU that provides onboard debug only. You can even use most
> > > > > > STM32 devkits as the debug probe (jumpers configurable). Latest
> > > > > > devkits use more powerful MCU for the onboard debug probe than
> the
> > > > > > target MCU few years back. There is a windoze based utility from
> > STM
> > > > > > that allows you to upgrade firmware and view / configure feature
> of
> > > > > > various STLink debug probes including those installed on
> devkits..
> > it
> > > > > > sometimes solves strange problems too :-)
> > > > > >
> > > > > > 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!! :-)
> > > > > >
> > > > > > https://www.youtube.com/watch?v=A4aCwoABGB8
> > > > > >
> > > > > > --
> > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Questions about STM32 support/programming
Posted by Matteo Golin <ma...@gmail.com>.
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, panic and
assertion and etc. calls are made, so it's good to know it's not a problem
with our LED code. I was able to turn them all on from the initialize
function as well.
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.
Matteo
On Fri, Jan 24, 2025, 6:25 PM Alan C. Assis <ac...@gmail.com> wrote:
> 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 on your board: common cathode / common anode.
>
> You need to keep it in mind to configure your board LED for diagnostics
> purposes correctly.
>
> BR,
>
> Alan
>
> On Fri, Jan 24, 2025 at 6:15 PM Matteo Golin <ma...@gmail.com>
> wrote:
>
> > 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
> there,
> > just at the wrong speed. The boot time is quite slow so I think something
> > may be wrong with our HSE.
> >
> > I have one question, which is that I'm noticing that the autoleds does
> not
> > seem to be working properly. I found that the `board_autoled_on` function
> > never seems to be called with LED_STARTED. I can turn on the LEDs if I
> set
> > them high in the `board_autoled_initialize` function though. In the
> > menuconfig options I saw that I can also enable
> > `CONFIG_ARCH_LEDS_CPU_ACTIVITY`. Is this needed to have
> > `board_autoled_on(LED_STARTED)` to occur?
> >
> > Thanks again for all your help!
> > Matteo
> >
> > On Thu, Jan 23, 2025 at 11:31 AM Alan C. Assis <ac...@gmail.com>
> wrote:
> >
> > > 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 I have it too. But it is always
> better
> > to
> > > use an open source solution when possible :-)
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Thu, Jan 23, 2025 at 5:46 AM raiden00pl <ra...@gmail.com>
> wrote:
> > >
> > > > > 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 debuggers in NuttX,
> like
> > > > SystemView.
> > > >
> > > > Last time I tested LWL it was terribly slow and heavily loaded the
> CPU
> > -
> > > > incomparably worse than RTT.
> > > >
> > > > Personally I recommend converting STLINK to JLINK if possible with
> > > >
> > > >
> > >
> >
> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
> > > > or even investing in a dedicated tool from Segger. It's really money
> > > worth
> > > > investment.
> > > >
> > > > śr., 22 sty 2025 o 22:45 Tomek CEDRO <to...@cedro.info> napisał(a):
> > > >
> > > > > On Wed, Jan 22, 2025 at 3:26 PM Matteo Golin <
> matteo.golin@gmail.com
> > >
> > > > > 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 provide JTAG/SWD interface for debug
> (USB
> > > > > HID), UART console (USB CDC), and filesystem storage for
> > drag-and-drop
> > > > > firmware flashing (USB MSC) over single USB connection. Even "dumb"
> > > > > FT2232 like probes have two channels one for JTAG/SWD and another
> for
> > > > > UART console :-)
> > > > >
> > > > > Most STLinks provide all 3 functionalities, except the old ones
> with
> > > > > small MCU that provides onboard debug only. You can even use most
> > > > > STM32 devkits as the debug probe (jumpers configurable). Latest
> > > > > devkits use more powerful MCU for the onboard debug probe than the
> > > > > target MCU few years back. There is a windoze based utility from
> STM
> > > > > that allows you to upgrade firmware and view / configure feature of
> > > > > various STLink debug probes including those installed on devkits..
> it
> > > > > sometimes solves strange problems too :-)
> > > > >
> > > > > 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!! :-)
> > > > >
> > > > > https://www.youtube.com/watch?v=A4aCwoABGB8
> > > > >
> > > > > --
> > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > >
> > > >
> > >
> >
>
Re: Questions about STM32 support/programming
Posted by "Alan C. Assis" <ac...@gmail.com>.
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 on your board: common cathode / common anode.
You need to keep it in mind to configure your board LED for diagnostics
purposes correctly.
BR,
Alan
On Fri, Jan 24, 2025 at 6:15 PM Matteo Golin <ma...@gmail.com> wrote:
> 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 there,
> just at the wrong speed. The boot time is quite slow so I think something
> may be wrong with our HSE.
>
> I have one question, which is that I'm noticing that the autoleds does not
> seem to be working properly. I found that the `board_autoled_on` function
> never seems to be called with LED_STARTED. I can turn on the LEDs if I set
> them high in the `board_autoled_initialize` function though. In the
> menuconfig options I saw that I can also enable
> `CONFIG_ARCH_LEDS_CPU_ACTIVITY`. Is this needed to have
> `board_autoled_on(LED_STARTED)` to occur?
>
> Thanks again for all your help!
> Matteo
>
> On Thu, Jan 23, 2025 at 11:31 AM Alan C. Assis <ac...@gmail.com> wrote:
>
> > 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 I have it too. But it is always better
> to
> > use an open source solution when possible :-)
> >
> > BR,
> >
> > Alan
> >
> > On Thu, Jan 23, 2025 at 5:46 AM raiden00pl <ra...@gmail.com> wrote:
> >
> > > > 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 debuggers in NuttX, like
> > > SystemView.
> > >
> > > Last time I tested LWL it was terribly slow and heavily loaded the CPU
> -
> > > incomparably worse than RTT.
> > >
> > > Personally I recommend converting STLINK to JLINK if possible with
> > >
> > >
> >
> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
> > > or even investing in a dedicated tool from Segger. It's really money
> > worth
> > > investment.
> > >
> > > śr., 22 sty 2025 o 22:45 Tomek CEDRO <to...@cedro.info> napisał(a):
> > >
> > > > On Wed, Jan 22, 2025 at 3:26 PM Matteo Golin <matteo.golin@gmail.com
> >
> > > > 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 provide JTAG/SWD interface for debug (USB
> > > > HID), UART console (USB CDC), and filesystem storage for
> drag-and-drop
> > > > firmware flashing (USB MSC) over single USB connection. Even "dumb"
> > > > FT2232 like probes have two channels one for JTAG/SWD and another for
> > > > UART console :-)
> > > >
> > > > Most STLinks provide all 3 functionalities, except the old ones with
> > > > small MCU that provides onboard debug only. You can even use most
> > > > STM32 devkits as the debug probe (jumpers configurable). Latest
> > > > devkits use more powerful MCU for the onboard debug probe than the
> > > > target MCU few years back. There is a windoze based utility from STM
> > > > that allows you to upgrade firmware and view / configure feature of
> > > > various STLink debug probes including those installed on devkits.. it
> > > > sometimes solves strange problems too :-)
> > > >
> > > > 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!! :-)
> > > >
> > > > https://www.youtube.com/watch?v=A4aCwoABGB8
> > > >
> > > > --
> > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > >
> > >
> >
>
Re: Questions about STM32 support/programming
Posted by Matteo Golin <ma...@gmail.com>.
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 there,
just at the wrong speed. The boot time is quite slow so I think something
may be wrong with our HSE.
I have one question, which is that I'm noticing that the autoleds does not
seem to be working properly. I found that the `board_autoled_on` function
never seems to be called with LED_STARTED. I can turn on the LEDs if I set
them high in the `board_autoled_initialize` function though. In the
menuconfig options I saw that I can also enable
`CONFIG_ARCH_LEDS_CPU_ACTIVITY`. Is this needed to have
`board_autoled_on(LED_STARTED)` to occur?
Thanks again for all your help!
Matteo
On Thu, Jan 23, 2025 at 11:31 AM Alan C. Assis <ac...@gmail.com> wrote:
> 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 I have it too. But it is always better to
> use an open source solution when possible :-)
>
> BR,
>
> Alan
>
> On Thu, Jan 23, 2025 at 5:46 AM raiden00pl <ra...@gmail.com> wrote:
>
> > > 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 debuggers in NuttX, like
> > SystemView.
> >
> > Last time I tested LWL it was terribly slow and heavily loaded the CPU -
> > incomparably worse than RTT.
> >
> > Personally I recommend converting STLINK to JLINK if possible with
> >
> >
> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
> > or even investing in a dedicated tool from Segger. It's really money
> worth
> > investment.
> >
> > śr., 22 sty 2025 o 22:45 Tomek CEDRO <to...@cedro.info> napisał(a):
> >
> > > On Wed, Jan 22, 2025 at 3:26 PM Matteo Golin <ma...@gmail.com>
> > > 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 provide JTAG/SWD interface for debug (USB
> > > HID), UART console (USB CDC), and filesystem storage for drag-and-drop
> > > firmware flashing (USB MSC) over single USB connection. Even "dumb"
> > > FT2232 like probes have two channels one for JTAG/SWD and another for
> > > UART console :-)
> > >
> > > Most STLinks provide all 3 functionalities, except the old ones with
> > > small MCU that provides onboard debug only. You can even use most
> > > STM32 devkits as the debug probe (jumpers configurable). Latest
> > > devkits use more powerful MCU for the onboard debug probe than the
> > > target MCU few years back. There is a windoze based utility from STM
> > > that allows you to upgrade firmware and view / configure feature of
> > > various STLink debug probes including those installed on devkits.. it
> > > sometimes solves strange problems too :-)
> > >
> > > 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!! :-)
> > >
> > > https://www.youtube.com/watch?v=A4aCwoABGB8
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
> >
>
Re: Questions about STM32 support/programming
Posted by "Alan C. Assis" <ac...@gmail.com>.
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 I have it too. But it is always better to
use an open source solution when possible :-)
BR,
Alan
On Thu, Jan 23, 2025 at 5:46 AM raiden00pl <ra...@gmail.com> wrote:
> > 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 debuggers in NuttX, like
> SystemView.
>
> Last time I tested LWL it was terribly slow and heavily loaded the CPU -
> incomparably worse than RTT.
>
> Personally I recommend converting STLINK to JLINK if possible with
>
> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
> or even investing in a dedicated tool from Segger. It's really money worth
> investment.
>
> śr., 22 sty 2025 o 22:45 Tomek CEDRO <to...@cedro.info> napisał(a):
>
> > On Wed, Jan 22, 2025 at 3:26 PM Matteo Golin <ma...@gmail.com>
> > 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 provide JTAG/SWD interface for debug (USB
> > HID), UART console (USB CDC), and filesystem storage for drag-and-drop
> > firmware flashing (USB MSC) over single USB connection. Even "dumb"
> > FT2232 like probes have two channels one for JTAG/SWD and another for
> > UART console :-)
> >
> > Most STLinks provide all 3 functionalities, except the old ones with
> > small MCU that provides onboard debug only. You can even use most
> > STM32 devkits as the debug probe (jumpers configurable). Latest
> > devkits use more powerful MCU for the onboard debug probe than the
> > target MCU few years back. There is a windoze based utility from STM
> > that allows you to upgrade firmware and view / configure feature of
> > various STLink debug probes including those installed on devkits.. it
> > sometimes solves strange problems too :-)
> >
> > 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!! :-)
> >
> > https://www.youtube.com/watch?v=A4aCwoABGB8
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
>
Re: Questions about STM32 support/programming
Posted by raiden00pl <ra...@gmail.com>.
> 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 debuggers in NuttX, like
SystemView.
Last time I tested LWL it was terribly slow and heavily loaded the CPU -
incomparably worse than RTT.
Personally I recommend converting STLINK to JLINK if possible with
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
or even investing in a dedicated tool from Segger. It's really money worth
investment.
śr., 22 sty 2025 o 22:45 Tomek CEDRO <to...@cedro.info> napisał(a):
> On Wed, Jan 22, 2025 at 3:26 PM Matteo Golin <ma...@gmail.com>
> 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 provide JTAG/SWD interface for debug (USB
> HID), UART console (USB CDC), and filesystem storage for drag-and-drop
> firmware flashing (USB MSC) over single USB connection. Even "dumb"
> FT2232 like probes have two channels one for JTAG/SWD and another for
> UART console :-)
>
> Most STLinks provide all 3 functionalities, except the old ones with
> small MCU that provides onboard debug only. You can even use most
> STM32 devkits as the debug probe (jumpers configurable). Latest
> devkits use more powerful MCU for the onboard debug probe than the
> target MCU few years back. There is a windoze based utility from STM
> that allows you to upgrade firmware and view / configure feature of
> various STLink debug probes including those installed on devkits.. it
> sometimes solves strange problems too :-)
>
> 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!! :-)
>
> https://www.youtube.com/watch?v=A4aCwoABGB8
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
Re: Questions about STM32 support/programming
Posted by Tomek CEDRO <to...@cedro.info>.
On Wed, Jan 22, 2025 at 3:26 PM Matteo Golin <ma...@gmail.com> 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 provide JTAG/SWD interface for debug (USB
HID), UART console (USB CDC), and filesystem storage for drag-and-drop
firmware flashing (USB MSC) over single USB connection. Even "dumb"
FT2232 like probes have two channels one for JTAG/SWD and another for
UART console :-)
Most STLinks provide all 3 functionalities, except the old ones with
small MCU that provides onboard debug only. You can even use most
STM32 devkits as the debug probe (jumpers configurable). Latest
devkits use more powerful MCU for the onboard debug probe than the
target MCU few years back. There is a windoze based utility from STM
that allows you to upgrade firmware and view / configure feature of
various STLink debug probes including those installed on devkits.. it
sometimes solves strange problems too :-)
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!! :-)
https://www.youtube.com/watch?v=A4aCwoABGB8
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Questions about STM32 support/programming
Posted by Sebastien Lorquet <se...@lorquet.fr>.
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 <ma...@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 <ma...@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
>>>
Re: Questions about STM32 support/programming
Posted by Matteo Golin <ma...@gmail.com>.
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 Sebastien suggested.
Thank you for your help,
Matteo
On Wed, Jan 22, 2025 at 11:35 AM Alan C. Assis <ac...@gmail.com> wrote:
> 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 manually looking at the datasheet
> (hard way, but it will pay off).
>
> If the serial pins are right, you can use a logic analyzer to see the
> "activity" coming from it.
>
> BR,
>
> Alan
>
>
> On Wed, Jan 22, 2025 at 12:59 PM Matteo Golin <ma...@gmail.com>
> wrote:
>
> > 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 understanding there
> is
> > flawed. I did also modify the UART console setup to use the same UART
> pins
> > as our board is set up to use. I thought of this approach based off of
> the
> > porting guide on the NuttX channel for another STM board, where an
> existing
> > board support tree we copied and modified slightly to boot. Maybe there
> is
> > more I did not consider. Good to know about the DFU at least!
> >
> > Thank you again,
> > Matteo
> >
> > On Wed, Jan 22, 2025 at 10:39 AM Alan C. Assis <ac...@gmail.com>
> 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 <ma...@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.golin@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
> > > > >
> > > >
> > >
> >
>
Re: Questions about STM32 support/programming
Posted by "Alan C. Assis" <ac...@gmail.com>.
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 manually looking at the datasheet
(hard way, but it will pay off).
If the serial pins are right, you can use a logic analyzer to see the
"activity" coming from it.
BR,
Alan
On Wed, Jan 22, 2025 at 12:59 PM Matteo Golin <ma...@gmail.com>
wrote:
> 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 understanding there is
> flawed. I did also modify the UART console setup to use the same UART pins
> as our board is set up to use. I thought of this approach based off of the
> porting guide on the NuttX channel for another STM board, where an existing
> board support tree we copied and modified slightly to boot. Maybe there is
> more I did not consider. Good to know about the DFU at least!
>
> Thank you again,
> Matteo
>
> On Wed, Jan 22, 2025 at 10:39 AM Alan C. Assis <ac...@gmail.com> 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 <ma...@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.golin@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
> > > >
> > >
> >
>
Re: Questions about STM32 support/programming
Posted by Matteo Golin <ma...@gmail.com>.
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 <ma...@gmail.com>
wrote:
> 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 understanding there is
> flawed. I did also modify the UART console setup to use the same UART pins
> as our board is set up to use. I thought of this approach based off of the
> porting guide on the NuttX channel for another STM board, where an existing
> board support tree we copied and modified slightly to boot. Maybe there is
> more I did not consider. Good to know about the DFU at least!
>
> Thank you again,
> Matteo
>
> On Wed, Jan 22, 2025 at 10:39 AM Alan C. Assis <ac...@gmail.com> 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 <ma...@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 <ma...@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
>> > >
>> >
>>
>
Re: Questions about STM32 support/programming
Posted by Matteo Golin <ma...@gmail.com>.
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 understanding there is
flawed. I did also modify the UART console setup to use the same UART pins
as our board is set up to use. I thought of this approach based off of the
porting guide on the NuttX channel for another STM board, where an existing
board support tree we copied and modified slightly to boot. Maybe there is
more I did not consider. Good to know about the DFU at least!
Thank you again,
Matteo
On Wed, Jan 22, 2025 at 10:39 AM Alan C. Assis <ac...@gmail.com> 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 <ma...@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 <ma...@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
> > >
> >
>
Re: Questions about STM32 support/programming
Posted by "Alan C. Assis" <ac...@gmail.com>.
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 <ma...@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 <ma...@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
> >
>
Re: Questions about STM32 support/programming
Posted by Matteo Golin <ma...@gmail.com>.
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 <ma...@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
>
Re: Questions about STM32 support/programming
Posted by Tomek CEDRO <to...@cedro.info>.
On Wed, Jan 22, 2025 at 2:48 AM Matteo Golin <ma...@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
Re: Questions about STM32 support/programming
Posted by Roberto Bucher <bu...@gmail.com>.
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
FLASH_FLAGS="-f $OPENOCD_DIR/interface/stlink.cfg -f
$OPENOCD_DIR/target/stm32h7x.cfg"
$FLASH $FLASH_FLAGS -c "program $1 verify reset exit"
==============
Bye
Roberto
On 1/22/25 2:51 AM, Matteo Golin wrote:
> For reference the command being used and its output is:
>
> $ openocd -f interface/stlink.cfg -f target/stm32h7x.cfg -c "program
> nuttx.bin 0x08000000 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-selecting first available session transport "hla_swd". To
> override use 'transport select <transport>'.
> Info : The selected transport took over low-level target control. The
> results might differ compared to plain JTAG/SWD
> Info : clock speed 1800 kHz
> Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
> Info : Target voltage: 3.308108
> Info : [stm32h7x.cpu0] Cortex-M7 r1p1 processor detected
> Info : [stm32h7x.cpu0] target has 8 breakpoints, 4 watchpoints
> Info : starting gdb server for stm32h7x.cpu0 on 3333
> Info : Listening on port 3333 for gdb connections
> [stm32h7x.cpu0] halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x0800136c msp: 0x24001ccc
> ** Programming Started **
> Info : Device: STM32H74x/75x
> Info : flash size probed value 2048k
> Info : STM32H7 flash has dual banks
> Info : Bank (0) size is 1024 kb, base address is 0x08000000
> Info : Padding image section 0 at 0x0801d5f8 with 8 bytes (bank write end
> alignment)
> Warn : Adding extra erase range, 0x0801d600 .. 0x0801ffff
> ** Programming Finished **
> ** Verify Started **
> ** Verified OK **
> ** Resetting Target **
> shutdown command invoked
>
> On Tue, Jan 21, 2025 at 8:47 PM Matteo Golin <ma...@gmail.com> wrote:
>
>> 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. We are able to
>> get access to its DFU loader via USB, and I can flash binaries to it.
>> However, it appears all of the H743 binaries that exist are for flashing
>> with an STLink or similar, not for DFU.
>>
>> 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. I have also
>> changed the definition of GPIO_LD1 (autoled) to be the pin PA4 where we
>> have our status LED, and updated the HSE clock to 24MHz to match the
>> frequency of the clock on our board. `ARCH_LEDS` is enabled and the USART1
>> pins have been modified to PB6 and PB7 to match our board setup. No luck
>> yet getting a shell or seeing an LED blink. Wondering if anyone with
>> experience porting to new STM32 boards has some debugging tips for us to
>> try.
>>
>> Thank you for all your help so far!
>> Matteo
>>
>> On Tue, Oct 1, 2024 at 9:36 AM Matteo Golin <ma...@gmail.com>
>> wrote:
>>
>>> 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 as possible since there are lots of different student members.
>>>
>>> Thank you for the programming information using openocd; that will be
>>> useful for us when it comes time to program,
>>> especially some of the example scripts. The Florida Institute of
>>> Technology project looks very interesting and is
>>> definitely something for us to read up about!
>>>
>>> Thanks everyone,
>>> Matteo
>>>
Re: Questions about STM32 support/programming
Posted by Matteo Golin <ma...@gmail.com>.
For reference the command being used and its output is:
$ openocd -f interface/stlink.cfg -f target/stm32h7x.cfg -c "program
nuttx.bin 0x08000000 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-selecting first available session transport "hla_swd". To
override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
Info : clock speed 1800 kHz
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.308108
Info : [stm32h7x.cpu0] Cortex-M7 r1p1 processor detected
Info : [stm32h7x.cpu0] target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
[stm32h7x.cpu0] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800136c msp: 0x24001ccc
** Programming Started **
Info : Device: STM32H74x/75x
Info : flash size probed value 2048k
Info : STM32H7 flash has dual banks
Info : Bank (0) size is 1024 kb, base address is 0x08000000
Info : Padding image section 0 at 0x0801d5f8 with 8 bytes (bank write end
alignment)
Warn : Adding extra erase range, 0x0801d600 .. 0x0801ffff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked
On Tue, Jan 21, 2025 at 8:47 PM Matteo Golin <ma...@gmail.com> wrote:
> 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. We are able to
> get access to its DFU loader via USB, and I can flash binaries to it.
> However, it appears all of the H743 binaries that exist are for flashing
> with an STLink or similar, not for DFU.
>
> 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. I have also
> changed the definition of GPIO_LD1 (autoled) to be the pin PA4 where we
> have our status LED, and updated the HSE clock to 24MHz to match the
> frequency of the clock on our board. `ARCH_LEDS` is enabled and the USART1
> pins have been modified to PB6 and PB7 to match our board setup. No luck
> yet getting a shell or seeing an LED blink. Wondering if anyone with
> experience porting to new STM32 boards has some debugging tips for us to
> try.
>
> Thank you for all your help so far!
> Matteo
>
> On Tue, Oct 1, 2024 at 9:36 AM Matteo Golin <ma...@gmail.com>
> wrote:
>
>> 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 as possible since there are lots of different student members.
>>
>> Thank you for the programming information using openocd; that will be
>> useful for us when it comes time to program,
>> especially some of the example scripts. The Florida Institute of
>> Technology project looks very interesting and is
>> definitely something for us to read up about!
>>
>> Thanks everyone,
>> Matteo
>>
>
Re: Questions about STM32 support/programming
Posted by Matteo Golin <ma...@gmail.com>.
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. We are able to
get access to its DFU loader via USB, and I can flash binaries to it.
However, it appears all of the H743 binaries that exist are for flashing
with an STLink or similar, not for DFU.
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. I have also
changed the definition of GPIO_LD1 (autoled) to be the pin PA4 where we
have our status LED, and updated the HSE clock to 24MHz to match the
frequency of the clock on our board. `ARCH_LEDS` is enabled and the USART1
pins have been modified to PB6 and PB7 to match our board setup. No luck
yet getting a shell or seeing an LED blink. Wondering if anyone with
experience porting to new STM32 boards has some debugging tips for us to
try.
Thank you for all your help so far!
Matteo
On Tue, Oct 1, 2024 at 9:36 AM Matteo Golin <ma...@gmail.com> wrote:
> 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 as possible since there are lots of different student members.
>
> Thank you for the programming information using openocd; that will be
> useful for us when it comes time to program,
> especially some of the example scripts. The Florida Institute of
> Technology project looks very interesting and is
> definitely something for us to read up about!
>
> Thanks everyone,
> Matteo
>
Re: Questions about STM32 support/programming
Posted by Matteo Golin <ma...@gmail.com>.
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 as possible since there are lots of different student members.
Thank you for the programming information using openocd; that will be useful for us when it comes time to program,
especially some of the example scripts. The Florida Institute of Technology project looks very interesting and is
definitely something for us to read up about!
Thanks everyone,
Matteo
Re: Questions about STM32 support/programming
Posted by Tomek CEDRO <to...@cedro.info>.
On Fri, Sep 27, 2024 at 4:17 PM <mi...@bofc.pl> 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', which could propagate it to
> make.def in board directory. I think something like that is mandatory if
> nuttx should be more popular. To be more popular it must get more user
> friendly. Not everyone wants to fight with bootloader/flashing. They just
> want to realize their idea - and not learn build system and flashing tools.
It is here already, at least in ESP32 family, probably needs to be
implemented for STM32.
Also ESP32 has esptool that covers almost all configurations.. while
different flashing configurations may be used for STM32 (i.e. openocd
vs dfu).. but it it still possible :-)
> I also hate to say that - but if you are commited to cmake (ugh) it might
> be good idea to drop raw Makefile support. This just makes things more
> complicated for both maintaners and end user - nuttx is giving kinda useless
> choice for the end user here I think ;)
Original approach was with Make and I use this one. CMake is currently
still under active development. Two choices whatever suits best :-)
> > Off the top of my head I don't remember whether the STMF7 family has a ROM
> > bootloader. If it does, you probably need to pay attention to a BOOT pin on
> > the chip.
> Nothing wrong in having 2 bootloaders. On chip bootloaders are often very
> limited and are more suited for recovery than final product usage. Custom
> bootloader can be relatively easily configure to - for example - fetch image
> from tftp and boot it - awesome for development.
The make flash part could use flags to select DFU or OpenOCD tool :-)
ps/2: Thanks Michal for the hint on how to flash STM32F3 with OpenOCD!
I have crerated PR with documentation update. If you have other hints
just let us know and we will update the documentation :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Questions about STM32 support/programming
Posted by mi...@bofc.pl.
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 haven't thought this through yet, so I don't know
> if it's feasible and what might be involved, but I thought I'd mention it
> here as food for thought.
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', which could propagate it to
make.def in board directory. I think something like that is mandatory if
nuttx should be more popular. To be more popular it must get more user
friendly. Not everyone wants to fight with bootloader/flashing. They just
want to realize their idea - and not learn build system and flashing tools.
I also hate to say that - but if you are commited to cmake (ugh) it might
be good idea to drop raw Makefile support. This just makes things more
complicated for both maintaners and end user - nuttx is giving kinda useless
choice for the end user here I think ;)
> Off the top of my head I don't remember whether the STMF7 family has a ROM
> bootloader. If it does, you probably need to pay attention to a BOOT pin on
> the chip.
Nothing wrong in having 2 bootloaders. On chip bootloaders are often very
limited and are more suited for recovery than final product usage. Custom
bootloader can be relatively easily configure to - for example - fetch image
from tftp and boot it - awesome for development.
--
.-----------------.-------------------.----------------------.-----------------.
| Michal Lyszczek | Embedded C, Linux | Company Address | .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter |
| https://bofc.pl `----.--------------: Brzezinka Sredzka PL | /`'\ & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer |
`----------------------^--------------^----------------------^-----------------'
Re: Questions about STM32 support/programming
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Sep 27, 2024 at 2:24 AM <mi...@bofc.pl> 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
> > NuttX build environment, or if it requires additional hardware.
> Hi, you should be able to flash and debug board via onboard stlink. All
> nucleos
> should have built-in stlink I think. So just connect nucleo via usb and
> check
> in lsusb if you have any stlink device. It should be visible like
> "STMicroelectronics STLINK-V3"
>
> I flash my boards with openocd:
>
> openocd -f interface/stlink.cfg -f target/stm32f3x.cfg -c 'program
> nuttx.bin 0x08000000'
>
> You will need to change your target, there is target/stm32f7x.cfg and
> target/stm32h7x.cfg already in the openocd. I am not sure if start of flash
> is 0x08000000 on f7 and h7, but I suppose it should be.
>
> This command will leave openocd opened with gdb server so you can start
> debugging it anytime you want with:
>
> arm-none-eabi-gdb nuttx "target remote 127.0.0.1:3333"
>
Something along these lines should be added to Documentation.
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 haven't thought this through yet, so I don't know
if it's feasible and what might be involved, but I thought I'd mention it
here as food for thought.
Another debugging idea, if you want a convenient GUI single-step debugger,
is to install the vendor's STM32Cube IDE, which (last I looked) is (was?)
an Eclipse-based IDE. You would need to fiddle with it to set up an IDE
project that calls the NuttX build system, loads the correct flash image,
and associates addresses to the correct source files (for source level
debugging), but I know it is possible.
Regarding USB bootloaders, in general (across all MCUs from all vendors)
you do need to first flash your bootloader to the chip using the chip's
primary flash/debug interface (be it SWD, JTAG, etc), *unless* the chip
already comes with a bootloader, either preprogrammed into the chip by the
vendor or in ROM.
Off the top of my head I don't remember whether the STMF7 family has a ROM
bootloader. If it does, you probably need to pay attention to a BOOT pin on
the chip.
Most development boards that you can buy from MCU vendors will connect to
your PC to be flashed and debugged through USB. However in most of those
cases, the board has a second smaller MCU from the same vendor which
implements the bridge between USB <-> JTAG/SWD/whatever and sometimes
supplies other information like the board's voltage. (It might be an option
for you to implement that kind of hardware on your custom board *BUT* I
would not recommend to attempt it unless the vendor supplies the hardware
schematics and firmware source code for it. Some vendors supply that,
sometimes in an Application Note, but many don't. Additional hardware also
means additional weight, which might be a bad thing in a weight-sensitive
application, not to mention additional cost.)
Hope this helps,
Nathan
Re: Questions about STM32 support/programming
Posted by mi...@bofc.pl.
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 additional hardware.
Hi, you should be able to flash and debug board via onboard stlink. All nucleos
should have built-in stlink I think. So just connect nucleo via usb and check
in lsusb if you have any stlink device. It should be visible like
"STMicroelectronics STLINK-V3"
I flash my boards with openocd:
openocd -f interface/stlink.cfg -f target/stm32f3x.cfg -c 'program nuttx.bin 0x08000000'
You will need to change your target, there is target/stm32f7x.cfg and
target/stm32h7x.cfg already in the openocd. I am not sure if start of flash
is 0x08000000 on f7 and h7, but I suppose it should be.
This command will leave openocd opened with gdb server so you can start
debugging it anytime you want with:
arm-none-eabi-gdb nuttx "target remote 127.0.0.1:3333"
--
.-----------------.-------------------.----------------------.-----------------.
| Michal Lyszczek | Embedded C, Linux | Company Address | .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter |
| https://bofc.pl `----.--------------: Brzezinka Sredzka PL | /`'\ & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer |
`----------------------^--------------^----------------------^-----------------'
Re: Questions about STM32 support/programming
Posted by Karukkuvel Raj D <ka...@gmail.com>.
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 you can upload the binary using either STM32Cube Programmer
> (GUI) or dfu-utils software (CLI).
>
> There are also other methods available, like using STLink connected to
> Debug pins of the MCU etc.
>
> Thanks and Regards
>
> Karukkuvel Raj D
>
> On 9/27/24 07:28, Matteo Golin wrote:
>> 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 the MCU listing the two most well documented variants are the STM32F7 and F4 it seems, but we're having trouble
>> deciphering how we would flash the MCU with NuttX from the instructions for the individual boards and on the main MCU
>> page.
>>
>> Example for the STM32F7, this page doesn't mention the programming interface/process:
>> https://nuttx.apache.org/docs/latest/platforms/arm/stm32f7/index.html
>>
>> Looking at an individual board with an F7 chip, the page for the Nucleo doesn't mention it either:
>> https://nuttx.apache.org/docs/latest/platforms/arm/stm32f7/boards/nucleo-f722/index.html
>>
>> The page for the board says it can only be programmed using ST-Link. We've done some research and found that most STM32s
>> were using the ST-Link programmer for programming, but it is also possible to load programs over USB using a USB
>> bootloader on some chips.
>>
>> 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 additional
>> hardware.
>>
>> I recalled seeing a porting livestream on the NuttX channel and checked out the board with an STM32F4 by Lucas Zampar,
>> and it appears to have serial wire debug and JTAG programming interfaces. I see there is also a USB interface but I'm
>> not sure if programming over it is possible:
>> https://github.com/lucaszampar/NuttX_STM32F4_RS485_DevBoard/blob/main/PDF/NuttX_STM32F4_RS485.pdf
>>
>> If so, it would be great to know how that is achieved! Many resources mention a USB bootloader but I'm not sure if it's
>> first required to upload the bootloader over SWD before being able to use it. I'm also not sure how this looks
>> specifically with NuttX's build system. It's highly possible I am just missing seeing some relevant information in the
>> NuttX docs but I can't seem to find what I'm looking for.
>>
>> Thanks,
>>
>> Matteo