Thread on nrf52840 dongle

[Gregory1992]

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?

[Jørgen Holmefjord]

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

[Gregory1992]

Thank for your help.

I flashed a dongle with Connect app using NCP for border router example hex from SDK:

nRF5_SDK_for_Thread_and_Zigbee_2.0.0_29775ac\examples\thread\ncp\usb_bootloader\hex

It seems that software is flashed, but I just want to know if this behavior is normal (photo attached).

To understand better I would like to ask: when you talk about "SES project settings" you mean some given environment?

I was just building *.hex using GNU make and importing it in Connect Programmer app. Is it a good way to do that? Where can I apply memory mapping changes that you mentioned doing it this way? I tried to make changes in linker script but don't see any difference after opening rebuilt hex in Proggramer app for now. 

For example I changed linker script "openthread_nrf52840.ld" like that: 

MEMORY
{
FLASH (rx) : ORIGIN = 0x1000, LENGTH = 0xfb000
RAM (rwx) : ORIGIN = 0x20000008, LENGTH = 0x3fff8
}

Could you please help me understand the problem with bootloader?

1. Are bootloader and MBR protected or is there risk of owerwriting them by a program? I mean if I load some hex that is mapped from memory start.

2. You said bootloader is placed flash from 0x0 to 0x1000, but on the Programmer screen I see MBR at the beginning (0x0 to 0x1000), then application and bootloader at the end of memory. Where is really bootloader placed in memory?

Thanks a lot

[Jørgen Holmefjord]

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.

[Mike Wazowski]

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?

[Jørgen Holmefjord]

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