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?
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?
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
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