1. Intro
We're developing a new IDE for microcontrollers (see https://embeetle.com) and would like to support a range of Nordic Semiconductor microcontrollers. We received the PCA10100 board (with nRF52833 microcontroller) on Embedded World 2020 from Mr. Reidar Martin Svendsen for this purpose.
2. The project
To support this board in Embeetle IDE, I first need to make a sample project that we'll add to our database of blinky-led sample projects. So I downloaded and unzipped the SDK:
C:/Nordic/nRF5_SDK_16.0.0_98a08e2/
In this SDK, I found the following blinky-led project:
C:/Nordic/nRF5_SDK_16.0.0_98a08e2/examples/peripheral/blinky_freertos/pca10100/blank/armgcc/
To build the project, I simply navigate to this folder and issue the make command. This works just fine. To flash the project to my board, I use the nrfjprog command-line tool, which works fine. The eventual goal is that we can do the flashing with OpenOCD, because that tool is included in our IDE. I've got a separate question for this issue: https://devzone.nordicsemi.com/f/nordic-q-a/59106/i-m-trying-to-support-nrf52833-in-embeetle-ide-but-flashing-through-openocd-gdb-doesn-t-work
3. The linkerscript problem
The project has two linkerscripts:
- examples/peripheral/blinky_freertos/pca10100/blank/armgcc/blinky_FreeRTOS_gcc_nrf52.ld
- modules/nrfx/mdk/nrf_common.ld
The first one blinky_FreeRTOS_gcc_nrf52.ld includes the second one nrf_common.ld. You can see that in the last statement:
INCLUDE "nrf_common.ld"
So here is what I did. I textually replaced this include statement with the actual content from nrf_common.ld. This looked like a very innocent thing to do, with the result that we've got one linkerscript instead of two. In case you're curious why I did this: we've got the habit in Embeetle to provide all sample projects with just one linkerscript.
Strangely, this quite innocent operation messed up the project. It still builds as if everything is just okay. But when I flash it to the microcontroller, the leds won't blink anymore. I've tried several times to make sure there is no hardware or other issue here. Again and again, I have to conclude that this innocent replacement of the include statement is the culprit.
