• State Suggested Answer
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 70 subscribers
  • Views 3304 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 293460
Options

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 

Parents
  • 0

    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

  • 0 in reply to Vidar Berg

    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 
  • 0 in reply to Vidar Berg

    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 

  • 0 in reply to mattmacleod

    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]);

  • 0 in reply to Vidar Berg

    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 
     

  • 0 in reply to mattmacleod

    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

  • 0 in reply to Vidar Berg

    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 

     

Reply
  • 0 in reply to Vidar Berg

    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 

     

Children
Related