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 2025/01/22 01:47:26 UTC

Re: Questions about STM32 support/programming

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 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
>>
>