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 >
