Flashing custom nRF52811 board with softdevice using OpenOCD

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?

Parents
  • 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.

  • 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.

  • Hi,

    It does not matter much if you are using the ST-Link or a J-link like the DK, but it is important that you are able to debug (not just program). Are you? If so, you can continue with the ST-Link. If not, I would work a bit more on getting debugging working. If it does not work, perhaps you did not connect VTG (see this post). Also, the supply voltage of your board must be about 3V in order to use the DK as a debugger.

    As you get blinky to work the basics are there, so I would make sure you can debug blinky. When you do, you can move on to try to debug a SoftDevice application. You should at least be able to see that you enter main(). If that does not happen, I would double check that you have programmed the SoftDevice, and that the application start address is correct. That needs to be the same as the size of the SoftDevice given in the release notes for the SoftDevice you are using. So when using S112 7.2.0, the application start address must be 0x19000.

  • I think the VTG connection was the issue. Or at least "SWD SEL" as it's marked on my DK. Now reading/writing flash shows the correct total size. However, when I flash both softdevice and application, the application gets merged into the softdevice for some reason. Not sure if this is just a visual glitch or could have something to do with the issue I'm experiencing. See flash layout below as shown in nRFConnect software.

Reply
  • I think the VTG connection was the issue. Or at least "SWD SEL" as it's marked on my DK. Now reading/writing flash shows the correct total size. However, when I flash both softdevice and application, the application gets merged into the softdevice for some reason. Not sure if this is just a visual glitch or could have something to do with the issue I'm experiencing. See flash layout below as shown in nRFConnect software.

Children
  • A few more interesting observations. I tried debugging both my BLE app as well as blinky and wasn't able to get far with either one.

    I used JLinkGDBServer -USB -device cortex-m4 to start a GDB server and arm-none-eabi-gdb to try and debug the firmware.

    In GDB I ran into the first issue, not knowing which file to load. I first tried file nRF5_SDK_17.1.0_ddde560/examples/peripheral/blinky/pca10056e/blank/armgcc/_build/nrf52811_xxaa.hex, but always got the response that this file doesn't contain any debug symbols. I could only step between two instructions for the blinky app and one instruction for the BLE app.

    # Blikly app
    (gdb) target remote localhost:2331
    Remote debugging using localhost:2331
    0x00000710 in ?? ()
    (gdb)
    (gdb) ni
    0x00000712 in ?? ()
    (gdb)
    0x00000710 in ?? ()
    (gdb)
    0x00000712 in ?? () 

    # BLE app
    (gdb) ni
    0x000189cc in ?? ()
    (gdb) ni
    0x000189cc in ?? ()
    (gdb) ni
    0x000189cc in ?? ()
    (gdb) ni
    0x000189cc in ?? ()
    (gdb) ni
    0x000189cc in ?? ()
    (gdb) ni
    0x000189cc in ?? ()
    (gdb) ni
    0x000189cc in ?? ()


    I later found, through trial and error, that the `.out` file contains debug symbols, so I decided to load that one instead. When loading the blinky example, here's what I got:

    1st try:

    (gdb) target remote localhost:2331
    Remote debugging using localhost:2331
    0x00000712 in delay_machine_code ()
    (gdb) n
    Single stepping until exit from function delay_machine_code.0,
    which has no line number information.
    0xdeadbeee in ?? ()
    (gdb) n
    Cannot find bounds of current function
    (gdb) n
    Cannot find bounds of current function
    (gdb) ni
    0xdeadbeee in ?? ()
    (gdb)
    0xdeadbeee in ?? ()
    (gdb)
    0xdeadbeee in ?? ()
    (gdb)
    0xdeadbeee in ?? ()

    2nd try:

    (gdb) target remote localhost:2331
    Remote debugging using localhost:2331
    0x00000712 in delay_machine_code ()
    (gdb) ni
    0x00000710 in delay_machine_code ()
    (gdb)
    0x00000712 in delay_machine_code ()
    (gdb)
    0x00000710 in delay_machine_code ()
    (gdb)
    0x00000712 in delay_machine_code ()
    (gdb)
    0x00000710 in delay_machine_code ()
    (gdb) n
    Single stepping until exit from function delay_machine_code.0,
    which has no line number information.
    nrf_delay_ms (ms_time=<optimized out>) at ../../../../../../components/libraries/delay/nrf_delay.h:73
    73 } while (--ms_time);
    (gdb) n
    72 nrf_delay_us(1000);
    (gdb) n
    73 } while (--ms_time);
    (gdb) n
    72 nrf_delay_us(1000);
    (gdb) n
    73 } while (--ms_time);
    (gdb) n
    72 nrf_delay_us(1000);
    (gdb) n
    73 } while (--ms_time);
    (gdb) n
    72 nrf_delay_us(1000);
    (gdb)
    73 } while (--ms_time);
    (gdb)
    72 nrf_delay_us(1000);
    (gdb)
    73 } while (--ms_time);
    (gdb)
    72 nrf_delay_us(1000);
    (gdb)
    73 } while (--ms_time);
    (gdb)
    72 nrf_delay_us(1000);
    (gdb)
    73 } while (--ms_time);

    This seemed to go into infinity

    (gdb) frame
    #0 nrf_delay_ms (ms_time=<optimized out>) at ../../../../../../components/libraries/delay/nrf_delay.h:73
    73 } while (--ms_time);
    (gdb) s
    72 nrf_delay_us(1000);
    (gdb)
    nrfx_coredep_delay_us (time_us=1000) at ../../../../../../modules/nrfx/soc/nrfx_coredep.h:173
    173 delay_cycles(cycles);
    (gdb)
    nrf_delay_ms (ms_time=<optimized out>) at ../../../../../../components/libraries/delay/nrf_delay.h:73
    73 } while (--ms_time);
    (gdb)
    72 nrf_delay_us(1000);
    (gdb)
    nrfx_coredep_delay_us (time_us=1000) at ../../../../../../modules/nrfx/soc/nrfx_coredep.h:173
    173 delay_cycles(cycles);
    (gdb)
    nrf_delay_ms (ms_time=<optimized out>) at ../../../../../../components/libraries/delay/nrf_delay.h:73
    73 } while (--ms_time);
    (gdb)
    72 nrf_delay_us(1000);
    (gdb)

    I was curious if this would ever end, so I let it run until it's past the current line. This however, turned out to be a bad idea, because after maybe a minute or two of it running through the loop, the target stopped responding. Even trying to power cycle the entire setup had no effect.

    nrf_delay_ms (ms_time=<optimized out>) at ../../../../../../components/libraries/delay/nrf_delay.h:73
    73 } while (--ms_time);
    (gdb)
    72 nrf_delay_us(1000);
    (gdb) u
    73 } while (--ms_time);
    (gdb) u

    Program received signal SIGTRAP, Trace/breakpoint trap.
    0xdeadbeee in ?? ()
    (gdb) frame
    #0 0xdeadbeee in ?? ()
    (gdb) target remote localhost:2331
    A program is being debugged already. Kill it? (y or n) y
    Remote debugging using localhost:2331

    Program received signal SIGTRAP, Trace/breakpoint trap.
    <signal handler called>
    (gdb) k
    Kill the program being debugged? (y or n) y
    Remote connection closed
    (gdb) target remote localhost:2331Quit
    (gdb) q

    Now the JLink on the DK appears to be in some weird state - when I try running JLinkGDBServer -USB -device cortex-m4, I get a popup, asking for the remote IP address, because it can't find a USB device. nrfconnect also doesn't detect any devices. Very weird. It's as if the DK is completely bricked. I also tried disconnecting the custom board completely to see, if I can flash the onboard nRF52840, but no luck. In all cases the LED next to JLink starts blinking really fast.

  • Also, in case this helps, here's the MEMORY section from my linker script. Looks like start address is correct and if I understand .hex files right, they should already contain the location in flash where the contents need to be placed. I think the only change I had to make here was increase the RAM origin by 0x10 (or something like that) to give softdevice more ram to handle a custom BLE service. Again, worked fine on DK, so I would assume it should be the same with nRF52811.

  • So today, the DK works again. Odd. I'm starting to suspect this USB hub I got recently.

Related