This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Thread on nrf52840 dongle

I would like to know if I can run Thread examples on nRF52840 USB dongle? Could someone provide instruction how to do this in a Windows environment?

Also, is there external debugging possibility for nrf52840 dongle?

Parents
  • Hi,

    Yes, it is possible to run Thread examples on the nRF52840 Dongle. The NCP USB Bootloader example in SDK for Thread and Zigbee v2.0.0 works on the dongle out-of-the-box. Other examples should also work, but you need to move the application in Flash and RAM for it to not overlap with the USB Bootloader, located from 0x0 to 0x1000 in Flash and 0x20000000 to 0x020000008 in RAM. The following settings are used in SES project settings (Section Placement Macros):

    FLASH_START=0x1000
    FLASH_SIZE=0xfb000
    RAM_START=0x20000008
    RAM_SIZE=0x3fff8

    The dongle can be debugged through the SWD interface, see the documentation.

    Best regards,
    Jørgen

  • The message in nRF Connect is normal when you flash an example that implements USB on the nRF IC. I was referring to the project settings in NCP example in Segger Embedded Studio. Changing the linker file used by GCC should give similar results. Which example did you build using GCC?

    1. Yes, the dongle use our serial DFU solution over USB to flash the IC. It will not allow you to overwrite MBR/Bootloader.
    2. Sorry, I meant to write MBR and not Bootloader. Bootloader is, as you correctly mention, placed close to top of flash.
  • Hi,

    NCP example runs perfect on Dongle after changing section placement and board header file, however the same does not apply to coap server and client examples. They compile just fine, but program does not seem to be running on dongle. Any tips to make it compatible?

  • My guess would be that one of the following things are causing issues:

    1. The examples initialize the Thread CLI module. The CLI module use UART port to communicate with external devices. The default UART ports used are P0.05-P0.08. These pins are used for other purposes on the Dongle, or they are not used and are left floating. Floating pins on UART peripheral can generate error codes and leaving the firmware in the error handler. Changing the pins will require rebuilding of the OpenThread libraries. You can also remove use of the CLI module, but note that you should then add this section into your code.
    2. The Dongle have different pinouts for Button and LED compared to the DK. If you do not change the preprocessor symbol that indicates which board is used, the example will initialize BSP with the LED and Button pins used on the nRF52840-DK. Changing the symbol from BOARD_PCA10056 to BOARD_PCA10059 could help with this issue.

    If you look in the dongle documentation, you can see that two of the colors of the LEDs are using the same GPIOs as UART peripheral on the DK.

    Connecting a debugger to the dongle will help you with debugging what is causing this issue. 

    Best regards,
    Jørgen

Reply
  • My guess would be that one of the following things are causing issues:

    1. The examples initialize the Thread CLI module. The CLI module use UART port to communicate with external devices. The default UART ports used are P0.05-P0.08. These pins are used for other purposes on the Dongle, or they are not used and are left floating. Floating pins on UART peripheral can generate error codes and leaving the firmware in the error handler. Changing the pins will require rebuilding of the OpenThread libraries. You can also remove use of the CLI module, but note that you should then add this section into your code.
    2. The Dongle have different pinouts for Button and LED compared to the DK. If you do not change the preprocessor symbol that indicates which board is used, the example will initialize BSP with the LED and Button pins used on the nRF52840-DK. Changing the symbol from BOARD_PCA10056 to BOARD_PCA10059 could help with this issue.

    If you look in the dongle documentation, you can see that two of the colors of the LEDs are using the same GPIOs as UART peripheral on the DK.

    Connecting a debugger to the dongle will help you with debugging what is causing this issue. 

    Best regards,
    Jørgen

Children
No Data
Related