Amazing!!! Kudos!!! On Sat, Jan 25, 2025 at 11:30 AM Matteo Golin <matteo.go...@gmail.com> wrote:
> Hi Alan, > > The issue was the soldering job, no fault of our NuttX configuration. There > was a short between a clock line and ground. The HSE now works totally > fine, and modifying the clock registers was actually very painless. They > were well commented and I only had to change a few multipliers to make the > frequencies line up. > > On Sat, Jan 25, 2025, 9:25 AM Alan C. Assis <acas...@gmail.com> wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
