Precompiled blinky .hex works, my compiled does not

[MarkR42]

Hi,

I've installed arm-gcc and the dev kit, I've tried several different versions.

I got it to compile the examples just fine. I can compile the example in examples/peripheral/blinky/pca10040/blank/armgcc/

I built my own dev board, and the problem is: using nrfjprog I can flash the precompiled example and it blinks the LED, but my compiled one does not. I don't understand exactly what's happening.

I'm using nRF5_SDK_14.2.0_17b948a and gcc gcc-arm-none-eabi-7-2017-q4-major on Ubuntu Linux x64_64.

My dev board is "rudimentary" but it contains a LED on GPIO20 and it flashes when the precompiled example runs. I can connect using nrfjprog and send new firmware. I am using a cheapo third party j-link cable.

One other thing - the LED blinks much slower (maybe about 4x slower) than it should. This might be because the chip is not running at the same speed as the real pca10040 dev board, I'm using a Bluenor BT832 module ("dead bug" soldered on a prototype strip-board with some LEDs and a reset button)

[MarkR42]

This seems quite interesting, I have managed to connect the debugger through segger into the board,

It gives me the following stack trace and registers:

(gdb) info reg

r0             0x3d09000        64000000
r1             0x848    2120
r2             0x20000000       536870912
r3             0x0      0
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x0      0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
sp             0x2000ffd8       0x2000ffd8
lr             0xfffffff9       4294967289
pc             0x406    0x406 <HardFault_Handler>
xpsr           0x61000003       1627389955
msp            0x0      0
psp            0x0      0
primask        0x0      0
basepri        0x0      0
faultmask      0x0      0
control        0x0      0
(gdb) bt
#0  HardFault_Handler () at /home/mark/toolchain/nRF5_SDK_14.2.0_17b948a/components/toolchain/gcc/gcc_startup_nrf52.S:300
#1  <signal handler called>
#2  0x00000000 in __isr_vector ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[MarkR42]

After further experiments, I'm now fairly sure that the third-party j-link cable I have is bad and is not uploading the firmware reliably or correctly. I will need to get an alternative and try again. Most surprising is that the sdk's .hex file ever flashed the LED at all.

[Simon]

I am sorry for the late reply, but it seems like you might have figured it out. Please ask if you encounter any more problems.

Best regards,

Simon

[MarkR42]

Right,  I've got a ST-LINK cable now, and I've managed to program the module using openocd.

OpenOCD seems to work as described here https://pcbreflux.blogspot.com/2016/09/nrf52832-first-steps-with-st-link-v2.html

Exactly as before, I can program the precompiled blinky.hex, and the led blinks, but I try to compile my own blinky using similar or identical source from the example, and it won't work.

I've tried loads of different versions of gcc and some versions of the SDK, something isn't quite right.

I can connect the debugger with openocd too, and the same as before it's showing the same stack trace. The debugger and the memory dump, etc, are all working in openocd.

I wonder if there's something which needs to be set up, which causes this module to fail shortly after boot.

I've tried a few things, such as dumping the contents of the flash and comparing it between the working and non-working version, but I don't really know where I'm going wrong.

Maybe I should try disassembling the precompiled blinky, to see if something is a bit different.

[MarkR42]

OK, I think I *MAY* have cracked it.

I think I've actually got a nrf52810 instead of the 32 version. This has less RAM, so it crashes when trying to use the stack which is at 64k,  but it only has 24k of ram.

For reasons which are unclear, the precompiled blinky example starts its stack pointer lower down, so it works!

I'm reading the specs, I think I ordered the BT832A module which has a 52810. Of course I can't see the writing on the chip, because it's under a tin lid like most of these modules.