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 

[Vidar Berg]

Hello Matt,

Does your custom board include the optional LF crystal shown in the ref. schematics below?

If not, and assuming you are using the DK board files,  please make sure you have selected the internal RC oscillator as the clock source for the netcore image too. These clock settings can be applied by adding a new config file in the child_image folder (/peripheral_uart/child_image/hci_rpmsg/boards). You can make a copy of the existing thingy53_nrf5340_cpunet.conf file and rename it to nrf5340dk_nrf5340_cpunet.conf.

Best regards,

Vidar

[mattmacleod]

Hi Vidar, 

Thanks for your reply. 

No, I do not have an external LF crystal. 

The program is still stuck in bt_enable() after making the following changes: 

1. Add the following lines to proj.conf: 

#config internal crystal for XL1/Xl2 oscillator

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_BT_SMP=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

2. Copy and rename following file /peripheral_uart/child_image/hci_rpmsg/boards/thingy53_nrf5340_cpunet.conf: 

3. Added the following lines to the nrf5340dk_nrf5340_cpunet.conf file:

#config internal crystal for XL1/Xl2 oscillator

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_BT_SMP=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

Any other suggestions? 

Kind regards, 

Matt 

[mattmacleod]

Hi Vidar, 

Thanks for your detailed response. 

I should also note that I am using an nrf5340-dk with VTG and VDD_nrf shorted together to re-direct the J-Link as my debugger for my custom board, where the SWD pins are connected to my custom board via the DKs Debug out port - if this information has any impact on your guidance. 

First I debugged netcore of my DK board using your above instructions and I was able to step through the network core to confirm proper procedure: 

Then I attempted to perform the same procedure you provided on my custom board and I wasnt able to step through at all, it appears to be locked out entirely. 

Do you have any other suggestions? 

Thanks for all your help. 

Matt  

[Vidar Berg]

Hi Matt,

mattmacleod said:

I should also note that I am using an nrf5340-dk with VTG and VDD_nrf shorted together to re-direct the J-Link as my debugger for my custom board, where the SWD pins are connected to my custom board via the DKs Debug out port - if this information has any impact on your guidance. 

This should be fine as long as the DK and custom board share the same VDD voltage (there is no built-in level shifter). I don't think this is the problem here considering you are able to program and debug the application core just fine.

mattmacleod said:

Then I attempted to perform the same procedure you provided on my custom board and I wasnt able to step through at all, it appears to be locked out entirely. 

Just to make sure, did you try to start the debug session for the application core first as suggested in the the documentation here: multicore debugging? This step is important as the app core is responsible for powering up the network core.

[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 

 

[Vidar Berg]

Hi Matt,

The connection loss could be a symptom of poor link quality. Do you have debug logging enabled in your peripheral project? It would be good to know what the disconnect reason is. For a bad connection I would expect the reason to be BT_HCI_ERR_CONN_TIMEOUT in most cases.

Also, it would be good if you could try to connect with it using the nRF connect app on Android or iOS to see if it gives you the same result.

Disconnect reason is logged over RTT if you use the peripheral_uart example as you can see here: https://github.com/nrfconnect/sdk-nrf/blob/2bee52d57e51cbe3108f0bbcb9ed68743bcd4e40/samples/bluetooth/peripheral_uart/src/main.c#L346

Vidar

[mattmacleod]

Hi Vedar, 

You are correct, I am getting the  BT_HCI_ERR_CONN_TIMEOUT  error when viewing the RTT logs. 

In my code, I am able to reliably connect to the other nrf5340-dk I am using as a central device, but it cuts out after a while and requires a reset to re-connect. 

As a test, I have an LED that turns on when the device is connected over BLE on my board. Then turns off when its disconnected. When connecting over nrf connect for IOS I am able to toggle the LED manually and the connection appears to be stable. It is when I try to send data over my service to the nrf5340-dk that is running the modified central application that I am running into this issue. 

Do you have any suggestions for what could be causing the  BT_HCI_ERR_CONN_TIMEOUT?

I already tried investigating the XFXO oscillator as a possible source of the issue since I was originally using external caps, so I re-configured the following for internal caps: 

1. Removing the external caps I had connected to the HFXO oscillator 

2. Calculating the internal CL values as 12.5pF for my XTal with a CL of 8pF 

3. Adding the following configs to both cores config files: 

CONFIG_SOC_HFXO_CAP_INTERNAL=y

CONFIG_SOC_HFXO_CAP_INT_VALUE_X2=25

Thanks again for all your help, 

Matt 

[Vidar Berg]

Hi Matt,

It's interesting that the central side has to be reset to re-connect. Isn't that supposed to happen automatically after a disconnect? I would suggest to check the debug logs from the central side as well, maybe there is an assert exception that causes the program to hang and require a reset to recover. Though I don't have a good explanation as to why this would only happen when connected to your custom board and not another DK.

There should not be an issue with the HFXO, or the LFCLK for that matter, as you are able to maintain the connection with your iOS device just fine.

Vidar