OpenOCD and the NRF not flashing complete HEX file

[Ronaldo Pace]

I'm trying to flash a nRF518122 with a St-Link V2 programmer via Open OCD. The process seems to goes smooth, but comparing the number of written bytes to the actual HEX size are not the same (about a third) and (of course) the nRF51 does nothing.

This is the open OCD config I'm using (supplied by the hardware guy, I'm not sure why setting WORKAREASIZE to zero, but without it it doesn't work).

source [find interface/stlink-v2.cfg]

set WORKAREASIZE 0x0
transport select "hla_swd"

source [find target/nrf51.cfg]

reset_config srst_only srst_nogate

then I type openocd -f file_above.cfg:

Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read
	openocd.org/.../bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.249474
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints

then telnet 127.0.0.1 4444:

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Open On-Chip Debugger

> halt

target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0x0000a152 msp: 0x20003964

> nrf51 mass_erase

Unknown device (HWID 0x0000008f)

> flash write_image <full_path>/zephyr.hex 0

Padding image section 0 with 2 bytes
not enough working area available(requested 32)
no working area available, falling back to slow memory writes
wrote 47164 bytes from file <full path>/zephyr.hex in 7.741681s (5.949 KiB/s)

The hex is compiled with gccarm from Zephyr-rtos_hci_uart (and changed the pins on nRF51_pca10028.defconfig to be the 1 and 2 as per WT51822 datasheet)

The same hex on pins 1-2 and the original hex compiled with the default pins 9-11 flashed via nRF Go to the nRF51-DK works without issues (via cables on pins 1-2 and the USB-UART connection respectively)

calling > flash banks gives me

#0 : nrf51.flash (nrf51) at 0x00000000, size 0x00040000, buswidth 1, chipwidth 1
#1 : nrf51.uicr (nrf51) at 0x10001000, size 0x00000100, buswidth 1, chipwidth 1

and I was wondering if Softdevice that came pre-programmed from the hardware guy is there and "taking space" and I have to re-order those banks, but I'm afraid of messing the bootloader, so I rather ask here before.

Any help appreciated.

update: I recompiled OpenOCD to add HWID 0x0000008f and now nrf51 mass_erase replies with nRF51822-QFAA(build code: H1) 256kB Flash but flashing still only goes up to 47164 bytes.

[RK]

Well your file is likely only 47164 bytes long. The size of the HEX file and the size of the actual binary it represent of course are radically different because HEX files are an ascii encoded format. The file transferred is the binary file. HEX files are about 2.5-3 times the size of the underlying binary.

Look at the map file created, that will tell you how big the application actually is.

[Ronaldo Pace]

and I thought I was going crazy. Thanks a lot. Now I'm using the generated .bin file to flash (instead of the hex) and managed to call flash read_bank and md5 the two. They match. I'm in talks to the hardware guy as the problem seems to be on hardware. Thanks.