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.

  • bjornolsen said:
    including using a J-Link to follow what is happening

    Did you erase the pre-programmed bootloader on the dongle? Or how did you flash the firmware that you are debugging?

    BR,
    Edvin

  • Hello.

    To be honest, I am not sure if I erase(d) the pre-programmed bootloader.
    All I do is to build a HEX file and the load it the the USB dongle. I do this using nrfutil and also using the programming tool. 

    For simple programs (that do NOT include BLE), the dongle works 100% fine. The issue is when I enable BLE (or try to run a BLE sample out of the box) this causes the dongle to crash.

    *** Booting Mesh Sensor Observer v2.9.1-31d0e132576e ***
    *** Using nRF Connect SDK v2.9.1-60d0d6c8d42d ***
    *** Using Zephyr OS v3.7.99-ca954a6216c9 ***
    Initializing...
    [00:00:00.010,620] <err> os: ***** BUS FAULT *****
    [00:00:00.010,620] <err> os:   Imprecise data bus error
    [00:00:00.010,650] <err> os: r0/a1:  0x000000c3  r1/a2:  0x00000000  r2/a3:  0x00000003
    [00:00:00.010,650] <err> os: r3/a4:  0x00000012 r12/ip:  0xaaaaaaaa r14/lr:  0x0001f349
    [00:00:00.010,681] <err> os:  xpsr:  0x81000000
    [00:00:00.010,681] <err> os: Faulting instruction address (r15/pc): 0x0001f2ea
    [00:00:00.010,711] <err> os: >>> ZEPHYR FATAL ERROR 26: Unknown error on CPU 0
    [00:00:00.010,772] <err> os: Current thread: 0x20003820 (shell_uart)
    [00:00:00.303,955] <err> fatal_error: Resetting system

    (log when I added my J-LINK)

    Yes I may need a "correct" bootloader if that is the issue, but how?

    Bjorn

  • I understand that you are struggling when the BLE stack is enabled, but there are no issues using BLE on the dongle, in itself. I am trying to figure out what causes the BLE stack to fail during initialization. That is why I am asking all these seemingly unrelated questions.

    Can you please try this for me. Connect your debugger (like you already have), and open nRF Connect for Desktop -> Programmer, select your programmer/debugger from the drop-down menu on the top left, and select "Read":

    This should provide some coloured stripes as shown on the right hand side in that screenshot.  What is currently present there? Feel free to also click "save to file" and upload it here, then I can investigate a bit more. 

    Note that this one is not from a dongle with a bootloader. It is just a DK with some simple application. 

    If the bootloader is in fact deleted, you need to decide whether you want to program it back in (I don't have it at hand, but I can find it). Or you need to make sure to add "CONFIG_BOARD_HAS_NRF5_BOOTLOADER=n" to your prj.conf, when building for the target board nrf52840dongle/nrf52840. 

    Are you currently building with CONFIG_BOARD_HAS_NRF5_BOOTLOADER=n, or not? Because the fact that the dongle is booting in the first place suggests that either CONFIG_BOARD_HAS_NRF5_BOOTLOADER=y (default value when building for the dongle), then the application (with or without softdevice) wouldn't start, unless the bootloader was present. Alternatively, you would not be able to flash it using "nrfutil dfu usb ..." 

    But if possible: upload the "save as file" .hex file, and zip and upload the application that you are currently testing. I assume you are still using NCS v2.9.0.

    Best regards,

    Edvin

  • 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.

Reply Children
  • 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

Related