BT_Enable Function stuck in bt_rpmsg_platform_endpoint_is_bound() for nrf5340

[mattmacleod]

Hello, 

I am having an issue with board bring up for a custom board I developed using the nrf5340 processor. 

I have created firmware based off the peripheral_uart sample that works on the nrf5340-dk.

My issue is my code is in bt_enable() only on the custom board, the code works perfectly fine on the dk board. 

It appears there is something wrong within the communication between the app and network core. When I step through the bt_enable function it looks like we are hung up in the following lines of code:

 

 

 

In the past I have been able to unlock the network core when running into issues on the dk boards with the following recovery/unlock commands but that didn’t seem to remedy the issue:

 

nrfjprog -f NRF53 --coprocessor CP_NETWORK --recover

nrfjprog -f NRF53 --coprocessor CP_NETWORK --program merged_CPUNET.hex --chiperase

nrfjprog --pinreset

 

It looks like quite a few people have had similar issues on the Dev Zone, but I don’t see a lot of answered tickets. 

Any help would be appreciated. 

Thanks, 

Matt 

[mattmacleod]

Hi Vidar, 

I am now able to debug the network core and I dont see any issues when stepping through the networkcore of the custom board compared to when I step through with my DK board. 

Strange finding:

The bt_enable function was hanging before debugging the network core, now after debugging the network core I can get out of the bt_enable function in VSCode... So that issue appears to be fixed. 

Is there some way that the network core got unlocked during this process? 

Thanks again for all your help, 

Matt 

[Vidar Berg]

Hi Matt,

This sounds promising. Are you able to connect to it over BLE as well? Also, does it still work after you exit debug mode?

mattmacleod said:

Is there some way that the network core got unlocked during this process? 

The network core is booted by the application core's FW on startup, so it should get powered on as long as the app core FW is being executed (link).

mattmacleod said:

I am now able to debug the network core and I dont see any issues when stepping through

The network core may be entering a bootloop if there is a failing assert in the hci_rpmsg FW and maybe mask the problem if there is one. You can set CONFIG_RESET_ON_FATAL_ERROR=n for the hci_rpmsg image to make it easier to catch such problems.

Lastly, as test, please try to run the code snippet below before bt_enable() to see if you are able to manually start the HF crystal (the program will get stuck in the while loop if not).

	NRF_TIMER1->BITMODE = TIMER_BITMODE_BITMODE_32Bit << TIMER_BITMODE_BITMODE_Pos;
	NRF_TIMER1->TASKS_CLEAR = 1;
	NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
	NRF_TIMER1->TASKS_START = 1;
	NRF_CLOCK->TASKS_HFCLKSTART = 1;
	while(NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);
	NRF_TIMER1->TASKS_CAPTURE[0] = 1;

	printk("HF Clock has started. Startup time: %d uS\n", NRF_TIMER1->CC[0]);

[mattmacleod]

Hi Vidar, 

Ive tried connecting to the device with a version of peripheral_central on another DK board and I am not able to connect to the custom board despite it clearing bt_Enable in the debugger. 

Note: this code works when I use it to connect to 2 DK boards so its not a software issue. 

I've added the following config: 

CONFIG_RESET_ON_FATAL_ERROR=n

In addition to adding the above lines of code and my program doesnt appear to be hanging in the following line as I can step over it (which seems promising): 

while(NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);

Do you have any other suggestions? 

Thanks for all your help, 

Matt 
 

[Vidar Berg]

Hi Matt,

I noticed you had provided your board schematics in a previous ticket, so I had a look at those, and I see you have opted to use external load capacitors for the 32M crystal. This is perfectly fine, but it is different from DK design where we use the internal load capacitors (Using internal capacitors).

Please add CONFIG_SOC_HFXO_CAP_EXTERNAL=y to your prj.conf file. This should ensure the XOSC32MCAPS (Retained) register stays at its reset value with the internal caps disabled.  You can start a debug session for the application core if you want to confirm the register setting afterwards:

If the current load capacitance is wrong as I suspect, you will end up with nominal frequency that is slightly off and shift the RADIO carrier frequency enough to make your advertisement packets "invisible" to your Bluetooth central device.

I hope this helps.

Vidar

[mattmacleod]

Hi Vidar, 

I added the following config:

CONFIG_SOC_HFXO_CAP_EXTERNAL=y to both app and network core. 

And confirmed the internal caps were disabled in ozone:

And it appears to be connecting (tested by sending a 240 byte buffer of dummy data to central) but the connection is not stable, it appears to be working, sending a few packets then the connection drops and I have to reset my board to reconnect where it again sends a few packets, then drops and requires a reset.    

This code was tested on the dk board so I dont believe it to be a software issue. 

Do you have any other suggestions? 

Thanks for your help, 

Matt