Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

nRF52 DK - Peripheral UART example unmodified fails if CONFIG_BT_SERVICES is enabled.

I'm testing out the Peripheral Uart example on the nRF52 DK with zero modifications using visual studio code.  However, when I run it, it constantly reboots.  When using the debugger, it seems to be that something in the bt_enable() function causes it to SIGTRAP.

This is the output of the debug console

Thread 9 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Remote target]
z_arm_is_synchronous_svc (esf=0x20006548 <z_main_stack+8>) at C:/ncs/v2.1.0-rc2/zephyr/arch/arm/core/aarch32/cortex_m/fault.c:649
649 uint16_t fault_insn = *(ret_addr - 1);

The RTT doesn't display anything.  And if I use the debugger, it dies in the z_arm_is_synchronous_svc() with a null pointer.

In doing some more digging, it seems the fault occurs with bt_settings_init().  If I turn CONFIG_BT_SERVICES off, the application seems to boot fine.  

This is a new DK and I've not paired it with anything in the past.  Not sure if this is exposing a bug associated with new hardware?

  • I'm using the VS Code gui and click on the flash button.  I have 2 nRF52 DK boards.  One is still in the 'virgin' state and the other has had some writes to the NV memory.  The virgin one still has this fault.  In digging through all the functions, the call it dies at is mpsl_timeslot_request()

    I did some googling and came across one account of the identical issue:  RE: Halt on nvs_init() 

    The stack trace of the issue is (btw, is there a way to copy this content as text from VS Code?)

    with it faulting on the call to mpsl_timeslot_request() on line 179

    Here is what's in memory at the time:

    When I try running it on my non-virgin DK with some NV writes - it never hits that line of code.  

    I went through to see what changed in the calling stack, and it never calls nvs_add_gc_done_ate(fs) on line 901 of nvs.c

    end:
    	/* If the sector is empty add a gc done ate to avoid having insufficient
    	 * space when doing gc.
    	 */
    	if ((!rc) && ((fs->ate_wra & ADDR_OFFS_MASK) ==
    		      (fs->sector_size - 2 * ate_size))) {
    
    		rc = nvs_add_gc_done_ate(fs);
    	}
    	k_mutex_unlock(&fs->nvs_lock);

    here are the variables  at that time

    Hope that helps,

    Reza

  • Hi Reza,

    Thanks for the debug information, it is for sure helpful!

    Can you try one more thing?

    For the "virgin" board, can you try to flash it using the "Erase and Flash" and see if it still gets the error?

    Regards,
    Sigurd Hellesvik

  •   I've lost track of which board is which, but when I click on the button you indicated, I indeed get the same reboot cycle happening again.

    I'm running the 2.1.0-rc2 SDK

    Here is my prj.conf (i left it unchanged):

    #
    # Copyright (c) 2018 Nordic Semiconductor
    #
    # SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
    #
    
    # Enable the UART driver
    CONFIG_UART_ASYNC_API=y
    CONFIG_NRFX_UARTE0=y
    CONFIG_SERIAL=y
    
    CONFIG_GPIO=y
    
    # Make sure printk is printing to the UART console
    CONFIG_CONSOLE=y
    CONFIG_UART_CONSOLE=y
    
    CONFIG_HEAP_MEM_POOL_SIZE=2048
    
    CONFIG_BT=y
    CONFIG_BT_PERIPHERAL=y
    CONFIG_BT_DEVICE_NAME="Nordic_UART_Service"
    CONFIG_BT_DEVICE_APPEARANCE=833
    CONFIG_BT_MAX_CONN=1
    CONFIG_BT_MAX_PAIRED=1
    
    # Enable the NUS service
    CONFIG_BT_NUS=y
    
    # Enable bonding
    CONFIG_BT_SETTINGS=y
    CONFIG_FLASH=y
    CONFIG_FLASH_PAGE_LAYOUT=y
    CONFIG_FLASH_MAP=y
    CONFIG_NVS=y
    CONFIG_SETTINGS=y
    
    # Enable DK LED and Buttons library
    CONFIG_DK_LIBRARY=y
    
    # This example requires more workqueue stack
    CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
    
    # Config logger
    CONFIG_LOG=y
    CONFIG_USE_SEGGER_RTT=y
    CONFIG_LOG_BACKEND_RTT=y
    CONFIG_LOG_BACKEND_UART=n
    
    CONFIG_ASSERT=y
    

  • Hi Reza,

    So far I have not been able to find a nRF52-DK which we have not used before at the office.

    If you want, you can read out the flash using

    nrfjprog --readcode flash.hex

    This way, we can have a closer look at the flash in your device, and I can compare it to another different nRF52DK to see if I can find any differences.

    Regards,
    Sigurd Hellesvik

  • I have also seen the same problem:

    Using an nRF52832 (with the nRF52 DK PCA10040).

    nRF Connect SDK 2.1.0 integrated with VS Code

    Using the peripheral_uart code and flashing that from a full erase, it seems that the device resets after passing bl_settings_init();

    However, as  has found, flashing the nvs example code prior to peripheral_uart fixes the reset issue.

    I have added two files:

    flash_beforenvs: This is running a mass erase followed by peripheral_uart

    flash_afternvs: This is running a mass erase, followed by nvs code, followed by peripheral_uart (with no erase in between nvs and peripheral_uart).

    flash_beforenvs.hexflash_afternvs.hex

    There are differences with these files...hopefully you all would know specifically how the diffs matter.

Related