mesh sensor observer sample on nrf52840 USB dongle

Hello,

I am developing a mesh solution when the nrf52840 USB dongle will act as an observer.

I am using the mesh sensor observer sample. I am able to build and flash it to the device. 

But I am unable to make the USB connection stable. 

I am adding this to the prj.conf (otherwise I am using the default prj.conf in the sample - and I am using SDK2.9)

CONFIG_GPIO=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="My USB Stick"
CONFIG_USB_DEVICE_MANUFACTURER="My company"
CONFIG_USB_DEVICE_SN="0001"
CONFIG_USB_CDC_ACM=y
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=y

CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

CONFIG_CJSON_LIB=y

and needed to add this to main file in order for the usb stick to show up at all.

int main(void)
{

	usb_enable(NULL);

    printk("USB enabled\n");
		
	uint32_t start = k_uptime_get();

	while (k_uptime_get() - start < 20000) {  // 20 seconds = 20000 ms
		k_sleep(K_SECONDS(1));
		printk("Printing before enabling BLE! %d\n", k_uptime_get_32());
	}
	

	printk("Starting...\n");

	int err;

	printk("Initializing...\n");

	err = bt_enable(bt_ready);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
	}

	return 0;
}

The output (I use python to read out from the USB port - pyserial) is:

📡 Connected to COM17 at 115200 baud
🔹 *** Booting Mesh Sensor Observer v2.9.0-54e858a1d142 ***
🔹 *** Using nRF Connect SDK v2.9.0-7787b2649840 ***
🔹 *** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
🔹 USB enabled
🔹
🔹 uart:~$ Printing before enabling BLE! 1003
🔹 Printing before enabling BLE! 2004
🔹 Printing before enabling BLE! 3004
🔹 Printing before enabling BLE! 4004
🔹 Printing before enabling BLE! 5005
🔹 Printing before enabling BLE! 6005
🔹 Printing before enabling BLE! 7005
🔹 Printing before enabling BLE! 8006
🔹 Printing before enabling BLE! 9006
🔹 Printing before enabling BLE! 10006
🔹 Printing before enabling BLE! 11007
🔹 Printing before enabling BLE! 12007
🔹 Printing before enabling BLE! 13007
🔹 Printing before enabling BLE! 14008
🔹 Printing before enabling BLE! 15008
🔹 Printing before enabling BLE! 16009
🔹 Printing before enabling BLE! 17009
🔹 Printing before enabling BLE! 18009
🔹 Printing before enabling BLE! 19010
🔹 Printing before enabling BLE! 20010
🔹 Starting...
⚠️ Serial error: ClearCommError failed (PermissionError(13, 'The device does not recognize the command.', None, 22))


So BLE conflicts with the USB - but how to fix this?

Parents
  • Hi,

     

    Since you are using usb for your logger, I assume that this line:

    ⚠️ Serial error: ClearCommError failed (PermissionError(13, 'The device does not recognize the command.', None, 22))

    Occurs due to an assertion (where the default behavior is a soft-reset). This then masks out the assertion log.

     

    My first guess would be a stack overflow, so try to adjust the CONFIG_MAIN_STACK_SIZE and see if the issue still occurs.

     

    Kind regards,

    Håkon

  • Hi Håkon.

    I increased the stack size several times - same issue.
    I guess the problem is that BLE somehow interfers with the UART console.
    It clear that it is doing a soft reset.

    It is not absolutely required to use the usb for the logger (although that would be nice). However, I do need to be able to communicate with the USB device.

    All suggestions are welcome.

  • I have never tried "BOARD_HAS_NRF5_BOOTLOADER=n" (or =y for that matter). But I tried it now Hello,



    We will eventually get to the bottom of this. 

    I am using SDK 2.9.

    I can program the USB dongle using "nRF Connect for Desktop BLE". Then the BLE works fine for the dongle. So yes, BLE does work on the dongle - this I know.

    Here is the programmer after I have programmed it in "nRF Connect for Desktop BLE". There is a nice soft device here, and it looks tidy. This of course works.




    I have never tried "BOARD_HAS_NRF5_BOOTLOADER=n" (or =y for that matter). But I tried it now and I get "prj.conf:99: warning: ignoring malformed line 'BOARD_HAS_NRF5_BOOTLOADER=n'". 

    When I flash my USB dongle with my own program - e.g. with BLE I cannot read it since it crashes at bootup... but after I reset the device (reset = pressing the button on the side), it looks like this.




    I did not have my debugger at hand - but I cannot see how that would help since the device dies when I flash it with BLE (when I use my own code).

    Right now I have programmed the dongle with a non-BLE application, which works 100%. 

    So something is clearly strange.

    maybe I can program it with "nRF Connect for Desktop BLE", and then somehow replace just the application. ..

  • I suspect the issue is that I am using "option 1" from https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/boards/nordic/nrf52840dongle/doc/index.html - then built-in bootloader. 

    the perflexiing thing to me is that it seems to work 100% fine except for applications including BLE.

  • bjornolsen said:
    I did not have my debugger at hand

    But to be clear, you did have a debugger at some point?

    For me to reproduce this, can you zip and upload the application that you are testing on, so that I can try to reproduce this?

    Best regards,

    Edvin

  • Hello again.

    Let me share some code and HEX. it may make things easier.

    This first example is a modified blinky_pwm with USB support.
    I have included the code + 2 overlay files, as well as the HEX for nrf52840DK and nrf52840dongle. When I flash it to each device it works 100% as expected. So all is good here.

    blinky_usb.zip

    below you will find the mesh_provisioner sample. I have only added output over UART here. This works 100% for nrf52840DK, but for nrf52840dongle I get no output (frozen device or similar). 

    mesh_provisioner_usb.zip


    This is why I feel that enableing BLE somehow creates a strange problem with nrf52840dongle.

    I am using SDK2.9.1

  • Hello,

    Sorry for the late reply. It seems like whatever sample you were starting from was not supporting the nRF52840 dongle board. 

    I have a dongle that I have soldered on a 10-pin header, so that I can attach an external debugger to it (but I always flash it using the pre-programmed bootloader. I use the debugger only for debugging and RTT logging). I changed all your printk() to LOG_INF(), and enabled RTT logging in prj.conf, and saw that it faulted in some storage related stuff (nvs = non-volatile storage):

    00> *** Booting nRF Connect SDK v2.9.1-60d0d6c8d42d ***
    00> *** Using Zephyr OS v3.7.99-ca954a6216c9 ***
    00> [00:00:00.000,366] <inf> app: Initializing...
    00> 
    00> [00:00:00.000,488] <inf> app: ✅ USB enabled
    00> 
    00> [00:00:00.004,302] <inf> fs_nvs: No GC Done marker found: restarting gc
    00> [00:00:00.004,669] <err> os: ***** BUS FAULT *****
    00> [00:00:00.004,669] <err> os:   Imprecise data bus error
    00> [00:00:00.004,669] <err> os: r0/a1:  0x200062bc  r1/a2:  0x00000000  r2/a3:  0x00000000
    00> [00:00:00.004,699] <err> os: r3/a4:  0x00000000 r12/ip:  0x20004580 r14/lr:  0x0003626b
    00> [00:00:00.004,699] <err> os:  xpsr:  0x41000000
    00> [00:00:00.004,699] <err> os: Faulting instruction address (r15/pc): 0x00032f6a
    00> [00:00:00.004,760] <err> os: >>> ZEPHYR FATAL ERROR 26: Unknown error on CPU 0
    00> [00:00:00.004,791] <err> os: Current thread: 0x20004580 (unknown)
    00> [00:00:00.340,454] <err> os: Halting system

    So this triggered when it tried to spin up the BLE stack, because it is dependent on storing some things in flash.

    I thought these were default settings for the board files for the dongle, but apparently it is not. So I found another sample that looked like it was actually tested on the nRF52840 dongle. The sample:

    ncs\nrf\samples\bluetooth\mesh\light_dimmer. If you look in that sample, you can see the file pm_static_nrf52840dongle_nrf52840.yml. It holds information about the nRF5 SDK bootloader that is pre-programmed in the dongle, and tells it where to put the NCS application's settings partition and so on.

    If you copy that file into your sample it should work. But for reference, I'll upload what I used to test as well, in case you want to try to attach a debugger for RTT logging. When you see asserts like these, the USB will stop working, and it is not possible to monitor the log about the crash information.

    mesh_provisioner_usb_2.zip

    Best regards,

    Edvin

Reply
  • Hello,

    Sorry for the late reply. It seems like whatever sample you were starting from was not supporting the nRF52840 dongle board. 

    I have a dongle that I have soldered on a 10-pin header, so that I can attach an external debugger to it (but I always flash it using the pre-programmed bootloader. I use the debugger only for debugging and RTT logging). I changed all your printk() to LOG_INF(), and enabled RTT logging in prj.conf, and saw that it faulted in some storage related stuff (nvs = non-volatile storage):

    00> *** Booting nRF Connect SDK v2.9.1-60d0d6c8d42d ***
    00> *** Using Zephyr OS v3.7.99-ca954a6216c9 ***
    00> [00:00:00.000,366] <inf> app: Initializing...
    00> 
    00> [00:00:00.000,488] <inf> app: ✅ USB enabled
    00> 
    00> [00:00:00.004,302] <inf> fs_nvs: No GC Done marker found: restarting gc
    00> [00:00:00.004,669] <err> os: ***** BUS FAULT *****
    00> [00:00:00.004,669] <err> os:   Imprecise data bus error
    00> [00:00:00.004,669] <err> os: r0/a1:  0x200062bc  r1/a2:  0x00000000  r2/a3:  0x00000000
    00> [00:00:00.004,699] <err> os: r3/a4:  0x00000000 r12/ip:  0x20004580 r14/lr:  0x0003626b
    00> [00:00:00.004,699] <err> os:  xpsr:  0x41000000
    00> [00:00:00.004,699] <err> os: Faulting instruction address (r15/pc): 0x00032f6a
    00> [00:00:00.004,760] <err> os: >>> ZEPHYR FATAL ERROR 26: Unknown error on CPU 0
    00> [00:00:00.004,791] <err> os: Current thread: 0x20004580 (unknown)
    00> [00:00:00.340,454] <err> os: Halting system

    So this triggered when it tried to spin up the BLE stack, because it is dependent on storing some things in flash.

    I thought these were default settings for the board files for the dongle, but apparently it is not. So I found another sample that looked like it was actually tested on the nRF52840 dongle. The sample:

    ncs\nrf\samples\bluetooth\mesh\light_dimmer. If you look in that sample, you can see the file pm_static_nrf52840dongle_nrf52840.yml. It holds information about the nRF5 SDK bootloader that is pre-programmed in the dongle, and tells it where to put the NCS application's settings partition and so on.

    If you copy that file into your sample it should work. But for reference, I'll upload what I used to test as well, in case you want to try to attach a debugger for RTT logging. When you see asserts like these, the USB will stop working, and it is not possible to monitor the log about the crash information.

    mesh_provisioner_usb_2.zip

    Best regards,

    Edvin

Children
No Data
Related