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.

[Ole Morten]

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.

[Ward WIllats]

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.

[chang sheng lung]

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.

[Ole Morten]

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.