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 

[Vidar Berg]

Hi Matt,

Thanks for confirming. At least it should not become stuck waiting for the LF crystal to ramp up now. The next step I would suggest is that you try to debug the netcore to try to find out exactly where the program is hanging (multicore debugging). Maybe the problem is with the 32 MHz crystal oscillator (HFXO) not starting up (The bluetooth controller will request this clock source whenever it is using the RADIO).

In vscode:

1. Make sure application core is selected.

2. Start debug session using vs code's debug extension or Ozone

1. Make sure the hci_rpmsg child image is selected

2. Start the 2nd debug session for the netcore

Kind regards,

Vidar

[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