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 > > > > > > > > > > > > > > >
