This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF51 fails when flashing: Target halted (PC = 0xFFFFFFFE)

Hi all,

I'm having a tight deadline upcoming and have run into an anoying problem.

I'm using this NRF51 breakout board: ohtcom.com/.../nrf51-m0-module I ordered a couple of devices from ebay a while back, and I tried soldering wires onto one of them and used my NRF51 Development Kit to program it. Worked like a charm.

Now I just got a batch of these breakout boards, and I can program and verify fine (Both softdevice and application) from nRFgo Studio, but nothing happens. It doesn't run.

When I try to download/start from eclipse it says:

Select auto target interface speed (1000 kHz)
Flash breakpoints enabled
Read 4 bytes @ address 0x000006D0 (Data = 0x4C174916)
Downloading 4096 bytes @ address 0x00018000 - Verified OK
Downloading 4096 bytes @ address 0x00019000 - Verified OK
Downloading 4096 bytes @ address 0x0001A000 - Verified OK
Downloading 4096 bytes @ address 0x0001B000 - Verified OK
Downloading 4095 bytes @ address 0x0001C000 - Verified OK
Downloading 8 bytes @ address 0x0001D000 - Verified OK
Downloading 436 bytes @ address 0x0001D008 - Verified OK
Comparing flash   [....................] Done.
Verifying flash   [....................] Done.
Writing register (PC = 0x0001bf94)
Read 4 bytes @ address 0x0001BF94 (Data = 0x480A2103)
Resetting target
Halting target CPU...
...Target halted (PC = 0x000006D0)
R0 = FFFFFFFF, R1 = FFFFFFFF, R2 = FFFFFFFF, R3 = FFFFFFFF
R4 = FFFFFFFF, R5 = FFFFFFFF, R6 = FFFFFFFF, R7 = FFFFFFFF
R8 = FFFFFFFF, R9 = FFFFFFFF, R10= FFFFFFFF, R11= FFFFFFFF
R12= FFFFFFFF, R13= 000007C0, MSP= 000007C0, PSP= FFFFFFFC
R14(LR) = FFFFFFFF, R15(PC) = 000006D0
XPSR C1000000, APSR C0000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes @ address 0x000006D0 (Data = 0x4C174916)
Starting target CPU...
...Target halted (PC = 0xFFFFFFFE)   <------------------------------------------CHECK THIS OUT
Reading all registers
Read 4 bytes @ address 0xFFFFFFFE (Data = 0x4C174916)
Read 4 bytes @ address 0x20007FFC (Data = 0x00000000)
Read 4 bytes @ address 0x20007FF8 (Data = 0x00000000)
Read 4 bytes @ address 0x00000000 (Data = 0x000007C0)
Read 4 bytes @ address 0x20007FF4 (Data = 0x00000000)
Read 4 bytes @ address 0x20007FF4 (Data = 0x00000000)
Read 4 bytes @ address 0x00000000 (Data = 0x000007C0)
Read 4 bytes @ address 0x20007FFC (Data = 0x00000000)
Read 4 bytes @ address 0x20007FF4 (Data = 0x00000000)
Read 4 bytes @ address 0xFFFFFFFF (Data = 0x000007C0)
Reading 64 bytes @ address 0x00000000
Reading 64 bytes @ address 0x00000040
Reading 64 bytes @ address 0xFFFFFFC0

Seems like it runs to an invalid address and get halted? But why?.. I've tried to erase chip -> program softdevice 110 -> program application, a dosen times. Doesn't work :(

---------------------------------- EDIT -----------------------------------------------

I just realized that my old boards (that work), are HW revision: nRF51822 CFACA00 , while new new ones that I can't get working is nRF51822 CEAAE00 (actually an older revision).

Anyway I looked in the compatibility matrix : www.nordicsemi.com/.../conten... Apparently the new once are a Revision 1 and should use nRFa51 SDK v.4.4.2 and S110 version 5.2.1 - I've tried to put SDK v. 8.0.0 into it. Probably therefore it isn't running.

My question now is: Where do I find the older version of the SDK and S110? AND more importantly, will my application (which I've designed and tested on the SDK v.8.0.0), still run with the older version of the SDK and S110? Are all interfaces intact?..

Parents
  • Just to be clear the SDK/Softdevice incompatibility, whilst an issue, most likely isn't the reason it's not running. As I said in my original reply, you've linked for a CFAC chip which had 32kB RAM and the stack pointer has been put at the top of that region. You've then used the same binary on a CEAA which only has 16kB of RAM so the stack pointer is pointing to invalid memory, which reads as zero, so on the first return from a routine you end up in the middle of nowhere.

    If you linked your code for 16kB, if it that's even enough memory, it would probably at least run, after a fashion. It wouldn't be production worthy, I wouldn't recommend it, but it would probably run.

Reply
  • Just to be clear the SDK/Softdevice incompatibility, whilst an issue, most likely isn't the reason it's not running. As I said in my original reply, you've linked for a CFAC chip which had 32kB RAM and the stack pointer has been put at the top of that region. You've then used the same binary on a CEAA which only has 16kB of RAM so the stack pointer is pointing to invalid memory, which reads as zero, so on the first return from a routine you end up in the middle of nowhere.

    If you linked your code for 16kB, if it that's even enough memory, it would probably at least run, after a fashion. It wouldn't be production worthy, I wouldn't recommend it, but it would probably run.

Children
No Data
Related