• State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Subscribers 73 subscribers
  • Views 5501 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 116748
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SD132 NRF52 gcc debugging

Martin

Hi

I'm trying to port my firmware to the NRF52 DK, but I'm having trouble getting it to work. Could you give me a hint based on the stack trace below, what the problem might be?

Thread #1 <main> (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)	
	0x20001248	
	<signal handler called>() at 0xfffffff9	
	0xf5bbf576	
	0x1000000

I'm using

  • SEGGER J-Link GDB Server V5.12g
  • gcc 5.4 q2
  • Eclipse Mars

Everything works fine for the NRF51 DK... This is driving me crazy..

Thanks for your hints in advance!

  • 0

    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?)

  • 0

    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.

  • 0

    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!

Related
Terms of service