• State Verified Answer
  • Replies 4 replies
  • Subscribers 67 subscribers
  • Views 4339 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 101541
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Hard-Fault on any interrupt in s110 soft device on nRF51822

Ward WIllats

We have a custom nrf15822-AA board flashed with the S110 (6.0.0) and our application. It has a 32khz crystal. It is connect to our (Mac) development systems with a SEGGER J-Link Ultra+.

Using GCC 4.7.4 and J-Link on the command line, all works fine.

I've been trying to bring the project up in Rowley Crossworks 3 and it's GCC. It runs, but It appears ANY interrupt (timer, RTC, GPIO) causes a hard-fault in the S110. Specifically, we stop at the hard-fault handler at 0x12ACE, and looking back on the stack, the hard-fault is apparently being generated at 0x12B50. If I let execution continue, it goes off into space.

The soft device is initialized before any interrupts are enabled. So it is active when this occurs.

Yes, we only use the sd_nvic routines.

Our interrupt vector table at 0x00014000 looks fine (but is never even read, AFAIKT - none of our handlers are ever entered).

The soft device appears to be loaded properly. (That is, whether I burn it with Crossworks or SEGGER, it lands at the same place.) It's IVT looks rational too.

Since this works with the GCC command line, it is obviously something with the Crossworks toolchain configuration. But since it is the S110 that is faulting, I thought I'd see if you folks have any thoughts.

Thanks.

Parents
  • 0

    You were correct, Ole. Thank you.

    I am using a preview of Crossworks 3 which will be released very soon. It has a BSP for the nrf51822. So everything I say here is related to that.

    The debugger directly loads the entry point address unless you go into the property sheet for the project and set the Entry Point Symbol in the Debugger Options to a non-existent symbol. In my case I used "doesnotexist" -- once this is done, the debugger will start execution at 0x4 instead of 0x14004.

    The early descriptive text in the BSP beta I first had did not make this clear. This text has since been made better.

    You must also:

    • Relocate the image to 0x00014000 by setting the project property Section Placement Macros in the Linker Options to: FLASH_START=0x14000;RAM_START=0x20002000

    • Optional: move the shared stack to the top of (AA) RAM. I chose a 2K stack, 1.5K for SoftDevice and 500 bytes for us. I did this by importing the flash_placement.xml file into the project (context-click and choose import) and adding a start="0x20003800" attribute to the .stack element.

    • Optional (but it made me feel better): Change the reset_handler: in Rowley's nRF51_Startup.s to point the initial SP for SystemInit to 0x20004000. Otherwise, SystemInit will run using a stack at the top of the SoftDevice's reserved RAM.

    • Define STARTUP_FROM_RESET in the file properties for nRF51_Startup.s

    We are a strange shop in that we like to develop embedded on Macintosh, in C++, with one of the smaller players in the tools market. For us, Crossworks performs very well, is nicely thought out, and we find the company much nicer to deal with than the 2 market leaders in the ARM tools world. But this default behavior of the debugger was certainly non-intuitive to me, even though I understand it now.

Reply
  • 0

    You were correct, Ole. Thank you.

    I am using a preview of Crossworks 3 which will be released very soon. It has a BSP for the nrf51822. So everything I say here is related to that.

    The debugger directly loads the entry point address unless you go into the property sheet for the project and set the Entry Point Symbol in the Debugger Options to a non-existent symbol. In my case I used "doesnotexist" -- once this is done, the debugger will start execution at 0x4 instead of 0x14004.

    The early descriptive text in the BSP beta I first had did not make this clear. This text has since been made better.

    You must also:

    • Relocate the image to 0x00014000 by setting the project property Section Placement Macros in the Linker Options to: FLASH_START=0x14000;RAM_START=0x20002000

    • Optional: move the shared stack to the top of (AA) RAM. I chose a 2K stack, 1.5K for SoftDevice and 500 bytes for us. I did this by importing the flash_placement.xml file into the project (context-click and choose import) and adding a start="0x20003800" attribute to the .stack element.

    • Optional (but it made me feel better): Change the reset_handler: in Rowley's nRF51_Startup.s to point the initial SP for SystemInit to 0x20004000. Otherwise, SystemInit will run using a stack at the top of the SoftDevice's reserved RAM.

    • Define STARTUP_FROM_RESET in the file properties for nRF51_Startup.s

    We are a strange shop in that we like to develop embedded on Macintosh, in C++, with one of the smaller players in the tools market. For us, Crossworks performs very well, is nicely thought out, and we find the company much nicer to deal with than the 2 market leaders in the ARM tools world. But this default behavior of the debugger was certainly non-intuitive to me, even though I understand it now.

Children
No Data
Related