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?

[Tadej]

Yes, app was built with correct headers. I started with the emulated version of ble_app_template example as a starting point which already uses S112, so I would assume everything is already correctly configured (except for the two defines which are mentioned here under "Transferring emulated project").

By "stuck" I mean that GDB hangs at that command and never returns, preventing me from entering any further commands. As mentioned in my previous post above, I let it run for a while and after a few minutes I ended up at address 0xdeadbeee.

During all tests I was also monitoring for the expected BLE device to show up on my phone, but it never appeared.

[Einar Thorsrud]

I hust admit I am more used to GUI debuggers and not GDB so I am not sure what it means when you the address is 0xdeadbeee, but that said, it seems like you are stepping? 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.

[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