Flashing custom nRF52811 board with softdevice using OpenOCD

[Tadej]

We are trying to flash our custom board with a modified version of the ble_app_template example (project based on nRF5_SDK_17.1.0_ddde560/examples/ble_peripheral/ble_app_template/pca10056e/s112/armgcc). The code has been validated on the PCA10056 DK with emulation for nRF52811.

To flash it to our custom board, I modified the Makefile as follows:

Changed the board define from BOARD_PCA10056 to BOARD_CUSTOM:

#CFLAGS += -DBOARD_PCA10056
CFLAGS += -DBOARD_CUSTOM

#ASMFLAGS += -DBOARD_PCA10056
ASMFLAGS += -DBOARD_CUSTOM

Removed DEVELOP_IN_NRF52840 define:

#CFLAGS += -DDEVELOP_IN_NRF52840

#ASMFLAGS += -DDEVELOP_IN_NRF52840

Removed NRFX_COREDEP_DELAY_US_LOOP_CYCLES=3 define:

#CFLAGS += -DNRFX_COREDEP_DELAY_US_LOOP_CYCLES=3

#ASMFLAGS += -DNRFX_COREDEP_DELAY_US_LOOP_CYCLES=3

I also created a minimal custom_board.h (bare minimum required for the firmware to compile; our custom board doesn't have any LEDs or buttons):

#ifndef CUSTOM_BOARD_H
#define CUSTOM_BOARD_H

#ifdef __cplusplus
extern "C" {
#endif

#include "nrf_gpio.h"

#define BUTTONS_NUMBER 0
#define BUTTONS_ACTIVE_STATE 0

#ifdef __cplusplus
}
#endif

#endif // CUSTOM_BOARD_H

To program the built binary and softdevice, I used OpenOCD with the ST-Link V2 programmer. The following command works as expected and flashes the two .hex files onto the nRF52811.

openocd -f interface/stlink.cfg -f target/nrf52.cfg -c "init; halt; program _build/nrf52811_xxaa.hex preverify verify; program ./nRF5_SDK_17.1.0_ddde560/components/softdevice/s112/hex/s112_nrf52_7.2.0_softdevice.hex preverify verify reset exit"

However, the BLE device doesn't show up as it did when developing on DK. How can we get more information on why this is failing? Where can we get NRF_LOG_* output from?

[Einar Thorsrud]

Hi,

The first thing that comes to mind as your application worked on a DK but not on your custom board is if your custom board has a 32.768 kHz crystal? If not, you need to configure the SoftDevice to use the LFRC instead, as explained in this post. And you need to make sure that you have followed the instructions under Transferring the project to nRF52811 hardware.

If that does not help, the next step is to start debugging to see what happens on the device.

As you have a DK, I would recommend that you use that as a debugger instead of the ST-Link, as that way you will be able to use all the tools we provide which works with J-Link out of the box. See Debug output in the DK documentation for details on how to use the DK as a debugger for an external device.

Regarding NRF_LOG_ output, you can get that either via UART or Segger RTT. If you have routed out pins for UART you can hook that up, and configure the logger module for use with UART. Or you can use RTT. In that case, you just need to use a Segger debugger (like a DK). See Logger module for details.

[Tadej]

Our board does have a 32.768 kHz crystal. However, I still tried to use LFRC, in case that would change anything, but had no luck. I also followed the instructions on how to transfer the project to nRF52811 - I started with an emulated project (examples/ble_peripheral/ble_app_template/pca10056e/s112/armgcc), so I only had to remove DEVELOP_IN_NRF52840 and NRFX_COREDEP_DELAY_US_LOOP_CYCLES.

I'm now trying to debug using the DK, but am also having issues. I shorted SB47 and connected our custom board to P20 (I'm powering our board from VDD nRF), but when I try to write/read flash, I end up writing/reading the nRF52840 that's on the DK. I know this, because I can still read/write the flash even when our custom board is disconnected and because the firmware works as expected (despite the two compiler defines being removed - DEVELOP_IN_NRF52840, NRFX_COREDEP_DELAY_US_LOOP_CYCLES).

I'm pretty suck at this point - not sure how to get the DK to flash our custom board. I saw SB19 next to SB47, so I'm wondering if I should short it as well? But SB19 appears to be undocumented, so I'm not even sure what it's for.

I can also add that the basic blinky example (examples/peripheral/blinky) flashed using ST-LINK works fine. It's only when I try to use BLE which requires the softdevice I start running into issues. I've also made sure to always flash the softdevice (S112), so that's definitely not missing.

[Tadej]

To me 0xdeadbeee is one off 0xdeadbeef which is often used to indicate some sort of failure. I'm not sure however, if that's read off the device or if it's just a way for the GDB server to report an error communicating with the device or something of that sort.

Which debugger are you more familiar with? I'll see if I can get that setup instead.

Not sure I understand what you mean by the following:

The SoftDevice will assert when stepping in most cases, so instead when using a SoftDevice, you can mimmic it by using a breakpoint, and move the breakpoint a bit further and reset to let it run to the next breakpoint, and so on.

[Einar Thorsrud]

Hi,

Yes, 0xdeadbeee clearly indicate an error, but I am not sure what. Regarding debugger, any GUI debugger usually works well for me :D You can for instance use Segger Ozone which works with any elf file. I don't have strong opinion about which debugger you use as long as you understand it, it is just that I am not able to help you with explaining why you see 0xdeadbeee.

Regarding the comment about stepping with a SoftDevice, that is because it seemed to me like you were stepping in the code, and that will not work with the SoftDevice most of the time. It will use RTC0 and TIMER0 to keep track of time, and if it detects that it has lost a event of some sort (because the timer elapsed while the CPU was halted), it will assert. So stepping (or continuing from a breakpoint for that matter) while using a SoftDevice will cause problems.

[Tadej]

So I tried flashing the unmodified ble_app_beacon (pca10056e) using SEGGER embedded studio and got the same result - firmware starts, but fails when initializing BLE. This time I used hardware without the 32.768 kHz crystal, so I followed the instructions to use LFRC instead, found here.

This is where I end up when running the firmware.

 

Using breakpoints, I was able to determine the abort happens at this point during ble initialization.

Setting a breakpoint at any point after this one (e.g. line 231) is never reached. However, nrf_sdh_enable_request() returns NRF_SUCCESS.

I'll verify the same happens on hardware with the 32.768 kHz crystal and update this post.

EDIT: So I just made an interesting discovery. For some reason, NRF_SDH_CLOCK_LF_SRC option change wasn't saved to sdk_config.h, which caused the abort. After fixing the configuration, firmware seems to run just fine (both on device with crystal and device with LFRC). However, I still can't see the BLE device. So at this point I'm investigating potential hardware issues. Would love to know, if there are still any potential software causes for this issue.

EDIT 2: Guess the option did save, but it appears there are three versions of the same option? Why is that?

NRF_SDH_CLOCK_LF_SRC
NRFX_CLOCK_CONFIG_LF_SRC
CLOCK_CONFIG_LF_SRC

[Tadej]

Great news. I attempted the same exercise with the ble_app_template example and got it working. Now it's just a matter of going through the process of elimination by incrementally adding custom features until it breaks again. Hopefully it'll be more clear what's going wrong after that.

[Tadej]

So after a few more hours of debugging, I finally found a solution. It all came down to not decreasing the RAM segment length in the linker script despite increasing the segment start address.

After incrementally adding back custom features to the ble_app_template, at one point I saw the project was working when building with SEGGER, but not when building with make - despite me only increasing the RAM segment start address and not decreasing the segment length in both SEGGER and linker script used in make. After some digging, I found that SEGGER was configured to calculate the segment length on-the-fly and appeared to completely ignore the configured segment length. This lead me to decreasing the segment length in the linker script, and now the make build works as well.