nRF54L15 stall in sdc_hci_cmd_le_set_adv_enable

[Nguyen Hoan Hoang]

Hi,

I'd like to know what is the cause of the stall in 

sym_E5Q6O4GY4KO3GMW7WJYXLZKHO7ZGDWLU4ZPAKWA() at 0xa55a

when calling sdc_hci_cmd_le_set_adv_enable ?

Here is the call stack : 

sym_E5Q6O4GY4KO3GMW7WJYXLZKHO7ZGDWLU4ZPAKWA() at 0xa55a
sym_JIJASGQH4XEEPZL7D35VQHVPKKLANGDBS2M46NQ() at 0x1c260
sym_P35ZNYRPUOIDHAE32RQYT4RWXL5RC6UIZKLHPUQ() at 0x1532e
sym_JU2KBYZVAT7EYGVZA4FU7TNK2PDUQNCWUBE5MWQ() at 0x15ca6
sdc_hci_cmd_le_set_adv_enable

It seems to be stuck in an infinite loop here : 

NOTE: The same code works fine on nRF52 series.  Yes, all IRQ handler are matched properly between nRF52 and nRF54 as per nrfxlib docs but no interrupts are generated on the nRF54.

Thanks,

[Hung Bui]

Hi a Hoang, 
Can you explain a little bit on what you are testing on ? 
If you test with simple BLE sample with the nRF54L does it work ? 

[Nguyen Hoan Hoang]

I am testing my own code using nrfxlib with softdevice controller directly. Just advertising sample.  There is some initialization that I am missing.  sdc seems to be waiting for a flag.  I just want to know what it is so I can initialize it 

[Nguyen Hoan Hoang]

It is not about the UART.  It's about BLE advertising.

[Hung Bui]

I undersand. What I suggest is to check why the HCI commands  (via UART ?) from the old iMAC managed to make it works (I assume it can advertise) but not the HCI commands from the new iMAC

[Nguyen Hoan Hoang]

Please review the original message.  It stalled.  Infinite loop waiting for something.  I want to know what.  

[Hung Bui]

I will check that when the R&D is back to full staff (next week). Could you please provide:

- Exact SDK version

- Your project configuration of the controller firmware

- List of commands to get to the stall. Please try to reproduce using minimal list of commands. 

- Please confirm that is you use older iMAC as the host it works and can advertise but if you use newer iMAC as the host it stalled. 

[Nguyen Hoan Hoang]

I am using the nrfxlib directly. Call sequences : 

sdc_hci_cmd_le_set_adv_params

sdc_hci_cmd_le_set_adv_data

sdc_hci_cmd_le_set_adv_enable.  It never returns from this function.

Call stack : 

sym_E5Q6O4GY4KO3GMW7WJYXLZKHO7ZGDWLU4ZPAKWA() at 0xa336
sym_JIJASGQH4XEEPZL7D35VQHVPKKLANGDBS2M46NQ() at 0x1bf48
sym_P35ZNYRPUOIDHAE32RQYT4RWXL5RC6UIZKLHPUQ() at 0x1501e
sym_JU2KBYZVAT7EYGVZA4FU7TNK2PDUQNCWUBE5MWQ() at 0x15996
BtAppAdvStart() at bt_app_sdc.cpp:515 0x1406 (Call sdc_hci_cmd_le_set_adv_enable)

This same results with the latest GitHub of the nrfxlib.

I know that is waiting for something.  There might be some initialization that I am missing.  I want to know which.  Does it require to risc-v coprocessor to run ? I have not initialized that part.

[Elfving]

Hi,

Hung is currently OOO, so I will take care of this case in the meantime.

I sent a quick question to the relevant team, and they say that this can happen when the GRTC is off. It would be better to not use the nrfxlib directly.

Regards,

Elfving

[Elfving]

This can be a bit tricky when simply trying to port an application. Both the GRTC and the syscounter needs to be running for it to work. 

You can have a look at this zephyr driver as a reference.

Regards,

Elfving

[Nguyen Hoan Hoang]

Ok so they are not started by the lib.  The docs didn't say that. Please review and modify the documentation accordingly. 

[Nguyen Hoan Hoang]

Initializing the GRTC from the firmware app works.  That was the missing link.  I thought it was supposed to be initialized by the mpsl similar to the nRF52.