How to create a working build for nRF52?

[mycleverbaby]

I managed to build fruitymesh for the nRF52 by using fruitymesh-ubuntu-vm. However after flashing it to nRF52 I don't get any output or command response on serial UART nor does any of the LED's on the dev board switch on, as simple test I also put a LedRed->On() into Main.cpp and that also does not get triggered, leading me to believe that something fundamental is wrong with my build.

Followed all the build instructions and "patch SDK file" instructions, changed board to NRF52_BOARD in the Makefile, then when trying to build there is another error about BOOTLOADERADDR not being defined in Module.cpp, fixed that by removing references to BOOTLOADERADDR and hardcoding as follows on line 70 of Module.cpp:

u32 bootloaderAddress = FLASH_SIZE;

Is it supposed to work on nRF52? Sorry if this is a stupid question, I am a beginner.

Here's my build output:

deploy@fruity-vb:~/nrf/projects/fruitymesh (master)*$ make
Making _build/debug/NRF52_BOARD
Compiling file: ble_radio_notification.c
Compiling file: nrf_drv_common.c
Compiling file: pstorage.c
Compiling file: nrf_drv_gpiote.c
Compiling file: app_timer.c
In file included from /home/deploy/nrf/sdk/nrf52_sdk_092//components/libraries/timer/app_timer.c:18:0:
/home/deploy/nrf/sdk/nrf52_sdk_092//components/drivers_nrf/delay/nrf_delay.h:162:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
 static void __INLINE nrf_delay_us(uint32_t volatile number_of_us) __attribute__((always_inline));
 ^
/home/deploy/nrf/sdk/nrf52_sdk_092//components/drivers_nrf/delay/nrf_delay.h:163:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
 static void __INLINE nrf_delay_us(uint32_t volatile number_of_us)
 ^
Compiling file: softdevice_handler.c
Compiling file: simple_uart.c
In file included from src/nrf/simple_uart.c:17:0:
/home/deploy/nrf/sdk/nrf52_sdk_092//components/drivers_nrf/delay/nrf_delay.h:162:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
 static void __INLINE nrf_delay_us(uint32_t volatile number_of_us) __attribute__((always_inline));
 ^
/home/deploy/nrf/sdk/nrf52_sdk_092//components/drivers_nrf/delay/nrf_delay.h:163:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
 static void __INLINE nrf_delay_us(uint32_t volatile number_of_us)
 ^
Compiling file: crc16.c
Compiling file: RTT_Syscalls_GCC.c
Compiling file: SEGGER_RTT.c
Compiling file: system_nrf52.c
Compiling file: Config.cpp
Compiling file: Main.cpp
Compiling file: AdvertisingController.cpp
Compiling file: GAPController.cpp
Compiling file: GATTController.cpp
Compiling file: ScanController.cpp
Compiling file: Connection.cpp
Compiling file: ConnectionManager.cpp
Compiling file: Node.cpp
Compiling file: AdvertisingModule.cpp
Compiling file: DebugModule.cpp
Compiling file: EnrollmentModule.cpp
Compiling file: IoModule.cpp
Compiling file: Module.cpp
Compiling file: ScanningModule.cpp
Compiling file: StatusReporterModule.cpp
Compiling file: SystemTest.cpp
Compiling file: TestBattery.cpp
Compiling file: Testing.cpp
Compiling file: ButtonListener.cpp
Compiling file: LedWrapper.cpp
Compiling file: Logger.cpp
Compiling file: NewStorage.cpp
Compiling file: PacketQueue.cpp
Compiling file: SimpleBuffer.cpp
Compiling file: SimplePushStack.cpp
Compiling file: SimpleQueue.cpp
Compiling file: Storage.cpp
Compiling file: Terminal.cpp
Compiling file: Utility.cpp
Compiling file: gcc_startup_nrf52.s
Linking target: FruityMesh.out
Preparing: FruityMesh.hex
 --------------------------------------------------------------
  Board:      NRF52_BOARD
  Platform:   NRF52
  Build type: debug

   text    data     bss     dec     hex filename
  72291     300    5036   77627   12f3b _build/debug/NRF52_BOARD/FruityMesh.out
 --------------------------------------------------------------

[mariusheil]

The build looks fairly good. You should avoid setting the Bootloader addr as there is no bootloader provided, so the value in the NRF_UICR->BOOTADDR (or similar) must not be set. Can you send me the changes you made to the makefile? When you test with LEDs you have to make sure that the correct pins are used. The default board is board_pca10031, you should check if the pins are the correct ones for your board. If uart is not working, you can try changing the terminalPromptMode variable in the Config.h because I have two different UART implementations. Which SDK version did you use?

Another thing to try is to attach a debugger, then you could see how your chip boots up. If its somewhere outside the code, somethings going wrong.

[mycleverbaby]

I used the following SDK: nRF5_SDK_11.0.0_89a8197 Together with the S132 v2.0.0 Softdevice Standard NRF52 Devkit which is the PCA10040

The change in the Makefile is just one line to hardcode to build for NR52 on line 6 of the Makefile as follows:

BOARD        ?= NRF52_BOARD

I will try the debugger

[mycleverbaby]

I configured the debugger and now see that it is not even going inside the code. I also now setup the windows eclipse environment, but that build has the same problem.

So I suspect something may be wrong with the Makefile for NRF52? As I setup 2 different build environments (the ubuntu VM and the windows eclipse environment) according to the instructions I believe its maybe not my build environment at fault?

[mariusheil]

Maybe I have some time tomorrow so I can have a look. Sorry, that I can not help you directly.

[mariusheil]

Hi, I just tested an older version and that one seems to work nicely with the NRF52. I don't have a lot of time right now, but I think you should find the difference in the current release that broke NRF52 support. Could be in the makefile, the linker script or somewhere in the Config or Main.cpp I guess. I've attached a version that works with the NRF52 fruitymesh.zip

[mycleverbaby]

Hi Marius, thanks so much, the version you attached compiles and runs fine on my NRF52 devkit! I will compare the difference and try to find the problem in the newer code.
Thanks!

[mariusheil]

Perfect :-) I've also been looking for some time now but haven't found it yet. The linker script was changed, I did a complete rewrite of the UART part and some more changes. I am reverting bit by bit but haven't found it yet. Now I have to switch to do some other stuff, but I gues you'll be able to find it :-)

[mycleverbaby]

problem is in nrf5x_common.ld , reverting the changes in there to what it is in the one you attached makes it work with the the latest code

[mariusheil]

Mhh, weird I had tested that as well but it didn't work. Looks like I had to restart my dev board and then it worked. Thanks a lot. Meshing and both Uart modes seem to work. There will be problems with module configurations when saving them to flash. I will have to fix this.

[dennis97519]

Hi, I'm trying to use this on RedBearLab BLE Nano v2 which uses a nRF52832 chip. The debugger and programmer is CMSIS-DAP. The softdevice and sdk version I'm using is exactly the same as above. The compiler version is 4.9 2015q3. I program the SoC by the means of drag and drop the hex file into the DAPLINK drive, softdevice first then FruityMesh.hex.

I tried the version you provided above and changed board_pca10040.h to match the pin number. It built successfully but I had the same problem as stated in the original post.

If I try to use openOCD debugger with the configuration files cmsis-dap.cfg and nordic_nrf52_dk.cfg, it shows that the PC jumps to 0xfffffffe and stops.

Is there something else that I can try?

Thank you!

[mariusheil]

Are you able to compile an official example project from Nordic with GCC and it will run on your board?

[dennis97519]

Thanks for the tip. I am not able to get a working hex with GCC... The precompiled hex provided in the SDK which works starts with the line

:020000040000FA

but the ones I got by running make starts with

:020000021000EC

I've tried 2015q1 version of GCC toolchain and got the same result. I'm using make.exe from GnuWin32.

[dennis97519]

Got it compiled on Keil using microlib, but without using any device family pack, without Heap info function (seems like no mallinfo() in ARM's stdlib). Also had to set heap size to 8192 to avoid getting into some sort of a hard fault.

[bymodude]

There will be problems with module configurations when saving them to flash. I will have to fix this.

would you be able to elaborate a bit on this? I just played around doing a simple "blinky" type custom module, I have not really played with saving configurations but should I expect them to be broken?

[mariusheil]

Closing this for now