gdb signal SIGTRAP 0x00014fde

[sam wagner]

Hi,

I am trying to bring up custom board with 51822 CFAC-A0. And I am continuously getting the following error as soon as the code does advertising_start(). I am using SDK7.2.0 and SD 7.1.0.

The address 0x00014fde appears to be from BLE stack. Please let me know what this issue could be...

Thanks, Sam

Type "apropos word" to search for commands related to "word"...
Reading symbols from _build/main_gcc_s110_xxac.elf...(no debugging symbols found)...done.
0xfffffffe in ?? ()
Loading section .text, size 0xaa27 lma 0x16000
Loading section .ARM.exidx, size 0x8 lma 0x20a28
Loading section .data, size 0xac lma 0x20a30
Start address 0x1cac0, load size 43739
info b 
Transfer rate: 10678 KB/sec, 3364 bytes/write.
Resetting target
Breakpoint 1 at 0x1687a
Breakpoint 2 at 0x1638c
(gdb) info b 
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x0001687a <main+14>
2       breakpoint     keep y   0x0001638c <advertising_start+60>
(gdb) c
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00014fde in ?? ()
(gdb) 

[Stian Røed Hafskjold]

Did you include the -g3 flag in the makefile? Did you run 'mon reset' after load? If you post your .out file I can try it in the debugger here.

[Lilligosi]

Hi. The same thing is happening to me as well. As soon as I start the soft device, run the following code

sd_mbr_command_t com= {SD_MBR_COMMAND_INIT_SD,}; sd_mbr_command(&com)

the code execution will stall. When I break the code manually the instruction pointer seems to be pointing to 0x14fde. I ran the exact same code on two computers and on one the code runs fine but the other it is stalling. The only difference between the two computers is the version of IAR ide that is used to compile the code. The one that works is running on version 7.20.2.7431 but the one that fails on 7.40.2.8570. I am using the same SDK and SD as Sam Wagner

[sam wagner]

Somehow the issue went away and I am not sure why... One thing we fixed was the clock frequency setting since we are using 32MHz crystal on the board and that seems to have fixed several issues.