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 <matteo.go...@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 <acas...@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 <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 >> > > >> > >> >
