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