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