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