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

  • 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

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

Children
No Data
Related