GDB zephyr.elf -- Asserts before main

[mjatmv]

I'm trying to use gdb to debug, I'm launching successfully and loading zephyr.elf. However, as I step through starting from reset.S the jump to "z_arm_prep_c" just asserts. The app works fine if I just flash it (.hex) fwiw.

Has anyone encountered this issue, or have suggestions at what I'm missing here?

(gdb) where
+where
#0 0xeffffffe in ?? ()
#1 0x0003b0d8 in z_arm_fault (msp=537039480, psp=<optimized out>, exc_return=<optimized out>, callee_regs=<optimized out>) at /home/kt/kt/src/embedded/ff/extern/ncs/zephyr/arch/arm/core/aarch32/cortex_m/fault.c:1029
#2 0x0003b348 in z_arm_usage_fault () at /home/kt/kt/src/embedded/ff/extern/ncs/zephyr/arch/arm/core/aarch32/cortex_m/fault_s.S:102
#3 <signal handler called>
#4 assert_post_action (file=0x4 "\255$", file@entry=0x7c23c "WEST_TOPDIR/zephyr/arch/arm/core/aarch32/cortex_m/fault.c", line=line@entry=1029) at /home/kt/kt/src/embedded/ff/extern/ncs/zephyr/lib/os/assert.c:43
#5 0x0003b0d8 in z_arm_fault (msp=537039688, psp=<optimized out>, exc_return=<optimized out>, callee_regs=<optimized out>) at /home/kt/kt/src/embedded/ff/extern/ncs/zephyr/arch/arm/core/aarch32/cortex_m/fault.c:1029
#6 0x0003b348 in z_arm_usage_fault () at /home/kt/kt/src/embedded/ff/extern/ncs/zephyr/arch/arm/core/aarch32/cortex_m/fault_s.S:102
#7 <signal handler called>
#8 0xaaaaaaaa in ?? ()

Flash starts up like:

I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot

GDB Looks like

I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
E: Image in the primary slot is not valid!
E: Unable to find bootable image

[Priyanka]

Hi Mitch,

I was a bit doubtful regarding this and had a discussion with an expert. So what might be happening is that, in the case that there are 3 images, say, the mcuboot, TFM and non-secure application, and when you do an incremental build, all 3 are updated, but when you launch the debug session, only the non-secure app is being replaced and this might cause the matching error. What is your sequence for entering the debug mode? i.e. the gdbinit section that yo run.

If you just flash the merged.hex and recompile your fw and then load only the non-secure app (which is what happens when you start the debug), this problem might occur. Did you only try attaching to the debug session, i.e. "cd build-folder && ninja attach"?

Have you tried an incremental compile? i.e. do you change the application compared to the initial merged.hex which was flashed onto the nRF9160?

-Priyanka

[mjatmv]

I have this working now by manually doing the gdb init process. I launch jlinkserver, then attach. First I load merged build, then change the file to zephyr elf file.Unfortunately the included commands to launch gdb are definitely not sufficient to work alone. Thank you!

[Priyanka]

Glad to hear that it works 

-Priyanka