BLE mesh: Using nRF52840 Dongle with sensor_server sample

When evaluating BLE mesh with multiple nodes the nRF52840 Dongle is perfect to keep cost and physical size down.

I thus have one nrf52840 DK and a couple of nRF52840 Dongles. To get started I would like to get the "sensor_client" and "sensor_server" samples provided with the nRF Connect SDK working on these. I know that these samples are not marked as compatible with the dongle, but I assume this is more due to missing support then missing HW capabilities (?)

Anyhow both samples seems to work fine on the DK and can be detected and provisioned by the nRF Mesh app. But none of them appears in the nRF Mesh app when programmed to the dongle. I am using Visual Studio Code with nRF Connect SDK, choosing the dongle board in the build configuration and flashing the dongle with the nRF programmer over USB. I have also verified that the dongle works fine with the "blinky" and "console" samples. This includes getting the console output to a serial terminal over USB.

Since there is no debugger in the dongle it would be very useful to get console access to monitor how the application is performing and find out why the BLE samples doesn't work on the dongle. I thus combined the "console" and the "sensor_server" samples from the nRF Connect SDK to a new application. This also works fine on the nrf52840 DK, and can be detected and provisioned by the nrf Mesh app. And the console is appearing on the nRF USB connector on the DK as expected, but with multiple lines like "[00:00:28.142,150] <inf> usb_cdc_acm: Ring buffer full, drain buffer" mixed with the printk() output from the app during boot. I also get similar output (including the ring buffer full spamming) when running this application on the dongle, but it stops after the "Initializing..." output from the sensor_server part of the code.

I am using:
Windows 10
nRF Connect for Desktop v3.12.0
ncs toolchain v2.20
zephyr v 3.2.99
nRF52840 DK v3.0.0 2022.34
nRF52840 Dongle v2.1.1 2022.37

So there are two issues:

1) What is preventing the sensor_ samples from running on the dongle? This should be easily reproducible by building and flashing the samples out of the box to a dongle with no changes except choosing the correct board.

2) Any suggestions on how to get rid of the console spamming during boot with the new combined application? I have googled and tried some of the suggestions from others having similar issues, but to no avail.

  • Thanks  , this works and the node on the Dongle can be provisioned now.

    I did notice earlier that the settings ended up in the bootloader section and tried to change that in the \zephyr\boards\arm\nrf52840dongle_nrf52840\fstab-stock.dts, but that change didn't seem to get picked up by the build system (?).

    I would like to keep the original partition settings when building for the DevKit. I thus tried to add the board name to the pm_static.yml filename as described in Configuring static partitions, but none of these are picked up (i.e. the partitions.yml file is back to default as without the pm_static.yml file) :

    pm_static_pca10059.yml
    pm_static_PCA10059.yml

    Any suggestions on how to achieve this?

  • Hi Ove,

    It seems I overlooked that last question of yours, sorry about that. I'm glad you got it figured out, even though you had to open a new ticket.

    Regards,

    Elfving

  • No problem! Actually I think it is easier to find solutions in DevZone when there is one question per ticket. So I will prefer to ask non-related follow up questions in separate tickets from now on :-)

    Regards,

    Ove

  • I just want to share a trick for anyone by mistake did not reset the node during unprovisioning using the NRF52840 usb dongle. As mentioned by Elfving, the bootloader/DFU can not erase the `settings_storage` section. 

    Not resetting the node from the Mesh mobile App will leave the setting and prevent the dongle to show in the scanning list. To solve this either one on of the following need to be followed: 

    1- Using external programmer. This is not desirable for most of us. 

    2- Erase the `settings_storage` section using a dummy firmware with calling erasing APIs. This is complicated solutions. 

    3- Modifying the start address of `settings_storage` section from the old start address  0xD8000 -> to a new one .i.e 0xD0000. 

    The modified pm_static.yml to the Elfving's would be: 

     

    app:
    address: 0x1000
    end_address: 0xD0000
    region: flash_primary
    size: 0xCF000
    nrf5_mbr:
    address: 0x0
    end_address: 0x1000
    placement:
    after:
    - start
    region: flash_primary
    size: 0x1000
    settings_storage:
    address: 0xD0000
    end_address: 0xE0000
    placement:
    align:
    start: 0x1000
    before:
    - end
    region: flash_primary
    size: 0x10000
    legacy_bootloader_storage:
    address: 0xE0000
    end_address: 0x100000
    placement:
    align:
    start: 0x1000
    before:
    - end
    region: flash_primary
    size: 0x20000
    sram_primary:
    address: 0x20000000
    end_address: 0x20040000
    region: sram_primary
    size: 0x40000

Related