Hi Erik, Thank you very much!
Nice finding. Maybe Matias used 16KB because it was failing when stack was small, and maybe it is failing now but silently because you said it is not adverting data. We need to get NuttX BLE with better support on NuttX. Currently we have NimBLE integrated, but Xiaomi team integrated the Zephyr stack on NuttX. I hope your company can use NuttX with BLE soon too! ;-) BR, Alan On 6/1/21, Erik Englund <erik.engl...@innoware.se> wrote: > Change the Nimble stacksize from 16384 to 2048, the nimble application > starts as it should. > Haven't had time to look into it anymore, it should've been 16k for a > reason. > > We´ll have to trim stacksizes to leave some ram for the actual application > though. > > I guess the board should start advertising some data, which it doesn't. > I´m not familiar with Mynewt/Nimble at all, our BLE products use the zephyr > rtos/stack together with MCUboot. > > > This is tested on nrf52832-dk. > > apps/wireless/bluetooth/nimble/Makefile > STACKSIZE = 2048 > > NuttShell (NSH) NuttX-10.1.0-RC1 > nsh> nimble & > nimble [5:255] > hci init > port init > gap init > gatt init > ans init > ias init > lls init > tps init > hci_sock task init > ble_host task init > nsh> hci sock task > host task > free > total used free largest nused nfree > Umem: 31120 26144 4976 4944 83 2 > nsh> ps > PID PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK USED > FILLED COMMAND > 0 0 FIFO Kthread N-- Ready 00000000 002048 000536 > 26.1% Idle Task > 1 224 RR Kthread --- Waiting Signal 00000000 002032 000600 > 29.5% hpwork > 2 100 RR Kthread --- Waiting Signal 00000000 002032 000600 > 29.5% lpwork > 3 100 RR Task --- Running 00000000 002032 001308 > 64.3% init > 4 100 RR Kthread --- Waiting MQ empty 00000000 001000 000408 > 40.8% BT HCI Tx > 5 255 RR Task --- Waiting Signal 00000000 002032 000856 > 42.1% nimble > 6 1 RR pthread --- Waiting MQ empty 00000000 002048 000440 > 21.4% pt-0x12bed 0 > 7 1 RR pthread --- Waiting Semaphore 00000000 002048 000736 > 35.9% pt-0x12c05 0 > nsh> > > > arm-none-eabi-size nuttx > text data bss dec hex filename > 313574 2340 29472 345386 5452a nuttx > > Med vänlig hälsning > Erik Englund > > Innoware Development AB > Hyttvägen 13 > > 73338 SALA > Org.nr. 556790-2977 > www.innoware.se > > > Den lör 29 maj 2021 kl 01:03 skrev Nathan Hartman <hartman.nat...@gmail.com >>: > >> On Fri, May 28, 2021 at 5:24 PM Alan Carvalho de Assis >> <acas...@gmail.com> >> wrote: >> >> > Hi Nathan, >> > >> > On 5/28/21, Nathan Hartman <hartman.nat...@gmail.com> wrote: >> > > On Fri, May 28, 2021 at 4:43 PM Alan Carvalho de Assis >> > > <acas...@gmail.com> wrote: >> > >> >> > >> Hi Erik, >> > >> >> > >> Thank you very much for your help. >> > >> >> > >> I noticed the final binary is too big (more than 300KB), is it also >> > >> happening to you? >> > >> >> > >> BR, >> > >> >> > >> Alan >> > > >> > > >> > > Do some sections in the linker script need (NOLOAD)? >> > > >> > > See PR-3198 [1], where the binary was also huge, until davids5 taught >> > > me about that: >> > > >> > > [1] https://github.com/apache/incubator-nuttx/pull/3198 >> > > >> > >> > Good question! >> > >> > When using external libraries with NuttX I need to use "--gc-sections" >> > to reduce the final size: >> > >> > >> > >> https://acassis.wordpress.com/2020/10/06/linking-external-libraries-on-nuttx/ >> > >> > BR, >> > >> > Alan >> >> >> >> Ah, yes, I use that too, together with -ffunction-sections and >> -fdata-sections, because the linker gc works at the granularity of a >> section. >> >> Did it work in this case? >> >> Nathan >> >
