Sorry, no idea. You should probably enable debugging and see what is happening.
Best, Matias On Tue, Jun 1, 2021, at 11:54, Alan Carvalho de Assis wrote: > After reducing the stack from 16KB to 2KB I got same result as yours Erik: > > 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 > > nsh> ifconfig > bnep0 Link encap:UNSPEC at UP > > Matias, do you have some idea why we are not seeing the BLE adverting? > > BR, > > Alan > > On 6/1/21, Erik Englund <erik.engl...@innoware.se > <mailto:erik.englund%40innoware.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 > > <mailto:hartman.nathan%40gmail.com> > >>: > > > >> On Fri, May 28, 2021 at 5:24 PM Alan Carvalho de Assis > >> <acas...@gmail.com <mailto:acassis%40gmail.com>> > >> wrote: > >> > >> > Hi Nathan, > >> > > >> > On 5/28/21, Nathan Hartman <hartman.nat...@gmail.com > >> > <mailto:hartman.nathan%40gmail.com>> wrote: > >> > > On Fri, May 28, 2021 at 4:43 PM Alan Carvalho de Assis > >> > > <acas...@gmail.com <mailto:acassis%40gmail.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 > >> > > >
