I finally got the composite USB stack working. Although both flash and ram are pretty maxed out...
The main item that kept me busy was CONFIG_DEFAULT_SMALL=y. This is causing a panic during mm_free in the AppBringUp task. Somewhere here: #0 mm_delayfree (heap=0x20000f58, mem=0x20000858 <g_kthread_group>, delay=<optimized out>) at mm_heap/mm_free.c:121 #1 0x08002028 in group_release (group=0x20000858 <g_kthread_group>) at group/group_leave.c:134 #2 group_leave (tcb=0x20001128) at group/group_leave.c:190 #3 0x080022ba in nxtask_exithook (tcb=<optimized out>, status=status@entry=0) at task/task_exithook.c:454 #4 0x08001cc6 in _exit (status=0) at task/exit.c:97 #5 0x08001c84 in nxtask_start () at task/task_start.c:112 #6 0x00000000 in ?? () I'll try to dig a bit deeper. I've seen some recent changes in that area. I tried to replicate it on an STM32U5 board, but setting DEFAULT_SMALL in the NSH config is simply breaking the build. On an IMX93 it works as expected. So there are some other dependencies at play. But the nastiest thing IMHO is the behavior of DEFAULT_SMALL itself. It 'works' when starting from a defconfig. But toggling it in menuconfig has different behavior due to how it's used in other configuration items. I'll be taking a wide curve around it in the future... Maarten On Thu, Mar 5, 2026 at 3:19 PM Matteo Golin <[email protected]> wrote: > > This is also something that was noticed by KR on AVR devices. > > An idea I've been toying with for CI (once I've gotten to know it better) > is selecting a couple "watched devices" to monitor the program size of > their defconfigs. Then maybe we can plot how NuttX is increasing in size > over time as we add patches. > > The smallest devices I own are AVR but I really never use them. It would be > good to start monitoring NuttX's ability to work on the small stuff again > since that's one of the things that makes it so cool. > > It's probably good to flag the defconfigs that have stopped working, and > even better if you could figure out the "breaking point" by bisecting. Then > maybe something could be done to shrink the RAM usage/build sizes. > > Matteo > > On Thu, Mar 5, 2026, 3:59 AM raiden00pl <[email protected]> wrote: > > > Go ahead Maarten, small systems on NuttX have been neglected lately. > > I don't know if anyone besides me has tried anything in this direction > > recently. > > Small systems require more fine-tuning, but NuttX allows for configuration > > of > > most features and stack sizes, so 20kB of RAM should be enough to create > > working applications, even with USB stack. If for some reason this is > > impossible > > now, it is a bug and should be fixed. I have a few STM32 boards with USB on > > my > > bench that I want to profile for "small systems" usage but I haven't found > > the time > > to do it yet. > > > > czw., 5 mar 2026 o 09:44 Tomek CEDRO <[email protected]> napisał(a): > > > > > Hey there Maarten, thanks for interest in NuttX! In the best scenario > > > we would want to bring back alive what is already in the code base :-) > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > On Thu, Mar 5, 2026 at 9:24 AM Maarten Zanders > > > <[email protected]> wrote: > > > > > > > > Hi, > > > > > > > > I have a couple of old devboards that I want to use in an experiment - > > > > Olimexino-STM32 - based on STM32F103RB. They are supported in NuttX > > > > but no documentation - so I wrote an extensive description. > > > > Unfortunately, none of the provided defconfigs are actually working: > > > > at each boot you're greeted with a backtrace. The (non-default) stack > > > > sizes are too small but, when increasing those, other things seem to > > > > be missing as well. Seems like NuttX evolved but nobody has been using > > > > these boards since a long time. There is also a lot of clutter in > > > > the defconfigs. > > > > > > > > So I started from scratch for a minimal NSH. Went further and tried to > > > > get USB composite up and running but after a day of fiddling I have to > > > > conclude that it's too much to ask from this chip with 20kB of RAM - > > > > at least without heavy tuning. As I don't need it myself, I won't be > > > > pursuing this any further. > > > > > > > > Now I'm wondering what's the best way to move forward? Is it OK to > > > > just delete code & configs that are not working anymore? I would then > > > > provide a clean base to start derived work from (but only a subset of > > > > current defconfigs). > > > > Or just mark what's there as "not functional" and move on? > > > > > > > > Cheers! > > > > Maarten > > > > >
