SD132 NRF52 gcc debugging

RE: SD132 NRF52 gcc debugging

Martin — Tue, 04 Oct 2016 16:34:30 GMT

Thanks for your help!

The hint with checking the Makefile and ld-file in deep was the clue... When moving my source files to the nrf52 makefile I copied the system_nrf51.c files... This lead to the odd behaviour...

Such a dumb mistake. Thanks for your time in pinning this down!

RE: SD132 NRF52 gcc debugging

Vidar Berg — Mon, 03 Oct 2016 10:26:10 GMT

Agree with what @butch is saying. I can't make much sense of register values other than that there is some memory corruption. I suspect this can be related to either the startup files or that the "common" linker script is for the 51.

Your .ld settings seems correct, worst case with these settings is that you get a "no mem" assertion when enabling the stack if the RAM base is too low. It should not end up in a hardfault.

I would suggest to use try with the example/ble_app_template/s132/ example, and change the makefile so that it includes your source files, and see if it makes any difference. This should at least ensure that the startup and linker configurations are correct.

RE: SD132 NRF52 gcc debugging

butch — Sun, 02 Oct 2016 14:51:30 GMT

Just thinking out loud... the lower nine bits of XPSR shows it is a hard fault. The PC is in RAM, which is strange. The SP is a very small number, which is strange, the stack is high in RAM and grows down? The LR is odd, aren't instructions word aligned? How did you choose your .ld file, since the example/ble_app_template/s132/....ld is different? I could be wrong on any of this. Are you able to step through assembly code and do you have a reading knowledge of assembler (that is how I might tackle this?)

RE: SD132 NRF52 gcc debugging

Martin — Sun, 02 Oct 2016 11:05:32 GMT

These are my ld-file settings:

MEMORY
    {
      FLASH (rx) : ORIGIN = 0x1f000, LENGTH = 0x61000
      RAM (rwx) :  ORIGIN = 0x20002080, LENGTH = 0xdf80
    }

The output of nrfjprog readregs is

R0:   0x0001E0D1
R1:   0x20001248
R2:   0x00002000
R3:   0x00000000
R4:   0x10001000
R5:   0x00000000
R6:   0x00000000
R7:   0x0001E0D1
R8:   0x00000000
R9:   0x00000000
R10:  0x00000000
R11:  0x00000000
R12:  0x00000000
SP:   0x20001230
LR:   0xFFFFFFF9
PC:   0x20001248
xPSR: 0x61000003
MSP:  0x20001230
PSP:  0x00000000

Meanwhile I also tried to compile with gcc 4.9 and 5.2 without success. The symptoms stay the same... :-(

RE: SD132 NRF52 gcc debugging

Martin — Fri, 30 Sep 2016 12:35:13 GMT

Upfront: I'm using SD132 V3. I paste the registers later. Hope this might help already.

RE: SD132 NRF52 gcc debugging

Vidar Berg — Fri, 30 Sep 2016 09:55:46 GMT

Looks like the sigtrap is occurring in the softdevice, hence no debug symbols. Please include the core register values in your description. You can do that from Eclipse, or call nrfjprog --readregs -f nrf52. Also which version of the SD are using?

RE: SD132 NRF52 gcc debugging

Martin — Fri, 30 Sep 2016 07:50:23 GMT

these are all my defines, some of them are project specific:

-DNRF52 
-D__HEAP_SIZE=0 
-D__VERSION_STR__=\"1.0.0.31\" 
-DSOFTDEVICE_PRESENT 
-DBOARD_PCA10040 
-DNRF52_PAN_12 
-DNRF52_PAN_15 
-DNRF52_PAN_58 
-DNRF52_PAN_55 
-DNRF52_PAN_54 
-DNRF52_PAN_31 
-DNRF52_PAN_30 
-DNRF52_PAN_51 
-DNRF52_PAN_36 
-DNRF52_PAN_53 
-DNRF_LOG_USES_RTT=1 
-DS132 
-DCONFIG_GPIO_AS_PINRESET 
-DBLE_STACK_SUPPORT_REQD 
-DSWI_DISABLE0 
-DNRF52_PAN_20 
-DNRF52_PAN_64 
-DNRF52_PAN_62 
-DNRF52_PAN_63 
-mcpu=cortex-m4 
-mthumb 
-mabi=aapcs 
--std=gnu99 
-mfloat-abi=hard 
-mfpu=fpv4-sp-d16 
-ffunction-sections 
-fdata-sections 
-fno-strict-aliasing 
-fno-builtin 
--short-enums  
-DBSP_DEFINES_ONLY 
-DREEDSWITCH 
-DUSE_EEPROM=1 
-DESB 
-DNRF_ESB_MAX_PAYLOAD_LENGTH=128 
-Wall -Werror -O0 -g3
-DDEBUG

But still no symbols - this is really puzzling me, as it works nice with the NRF51...

RE: SD132 NRF52 gcc debugging

butch — Thu, 29 Sep 2016 20:18:48 GMT

Can't you compile with debug symbols built into the object file (CFLAGS += -DDEBUG) so gdb can print out a readable trace? Even if you could determine which handler was called (at ...ffff9) , with debug symbols compiled in the trace would tell you the name of the last function called etc.