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

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

Ole Morten — Fri, 21 Mar 2014 18:00:00 GMT

This is really an separate question that would have been better off separately. However, with IAR you can try adding "--drv_vector_table_base=0x0" in Options > Debugger > Extra Options > Command line options. Also make sure to use a recent version, at least 6.60.3.

If you have further problems, please post a separate question.

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

chang sheng lung — Fri, 21 Mar 2014 08:58:57 GMT

hi Ole,

I have the same problem, and the IDE I am using is IAR. could you provide more info for me the fix the issue.

Thanks.

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

Ward WIllats — Fri, 07 Feb 2014 21:31:14 GMT

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.

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

Ole Morten — Fri, 07 Feb 2014 12:01:11 GMT

Could it be that Rowley doesn't reset the chip properly? It seems it's likely that it fails in this way if the forward address hasn't been set correctly, and this may happen if the softdevice's reset handler haven't been run.

I'd hence recommend you to see if you have any way of controlling where the debugger starts the chip, and if you do, make sure that it starts at the reset handler on address 0x04, not on 0x14004. Adding an additional debugger-initiated reset right after launch may also help, but I'm not familiar with Rowley so I can't say exactly how you can do this.

We've previously seen this issue with both Eclipse and IAR, and I'm honestly a little surprised that the IDEs do this, since a Cortex M0 will by spec always start at 0x0 when free-running. The similar question for Eclipse is here, but the IAR case was handled in the regular support system, so I can't link to details.