search

nordic-auko / nRF5-ble-timesync-demo

nRF52 clock synchronization demo code
55 stars 50 forks source link

Misplaced entry point? Hard faulting from components/libraries/nrf_log_frontend.c:112 #22

Closed embeddedpenguin closed 2 years ago

embeddedpenguin commented 2 years ago

image

I cannot break at main. Every time code is loaded, I'm immediately thrown into nrf_log_frontend.c:112 and it hard faults. I've tried using make flash, but this does the same thing. My main method of pushing code is using openocd and arm-none-eabi-gdb for debugging. I've tried enabling logging in the config file, and I've also tried disabling logging in the config file. Both give me the same result. I've also tried using the toolchain from arm (10.3.1) and the version from my package manager (12.1.1). All give me the same result.

When trying to place a breakpoint at main, gdb thinks main is at nrf_log_frontend.c:112 image

I'm new to nrf and its sdk so this could just be something I'm doing wrong, but I figured this demo was more plug and play than anything else.

embeddedpenguin commented 2 years ago

I've also confirmed that I can flash and debug using elf files created by nrf connect w/vscode. So it's gotta be my .out file is bad. Or I'm loading at the incorrect address or something.

embeddedpenguin commented 2 years ago

Switching to sdk16 branch solved this.

embeddedpenguin commented 2 years ago

Turns out switching branches did nothing. I mean it did something, but today I opened up the same project and tried to flash another board and got the same issue. Even using nrfjprog fails to flash the device. Nevermind. It's something to do with openocd. If I recover the device, then chip erase, then make flash, it works. Openocd, however, does not work for loading code. It only works for attaching and debugging, although even that is really weird (even when using JlinkGDBServer and not using openocd). It takes 4 or 5 nexts to actually get to the next line.

nordic-auko commented 2 years ago

Hello, do you use the entry point address from the .elf file, or address 0x00? The debugger is generally not aware of the SoftDevice, and can try to start the application from the address in the .elf file. However, for the softdevice to work correctly it needs the CPU to begin executing from address 0x00.

embeddedpenguin commented 2 years ago

The issue was for some reason some of my soft device was being erased when using openocd, and so there was a weird ritual where I would flash the soft device first and then the app hex, and then I would hard fault upon entry. Fixed this by using mergehex when using openocd, but just going to use nrfjprog from now on because it seems to work.