Porting HRS Example to IAR - Crash at SVC 0x10

[Jeff Wormsley]

I'm trying to port the HRS example using S110 Softdevice and SDK 7.1.0 to IAR 7.10 on the pca10028 board.

I've created an IAR project which uses the same files as the Keil version, using the Keil limited demo IDE to determine the paths of each file, and each dependency. The only exception is the arm_startup_nrf51.s is replaced by iar_startup_nrf51.s. I also created a linker .icf file to set the memory regions and stack sizes, as well as the intvec location. This was copied from the file included with IAR 7.10 and placed into the same folder as main.c.

I use nRFGo to erase the part, then load the soft device. I can build the Keil demo and run it, and use the nRFToolbox app's Heartrate Monitor function to see the output from the board.

If I duplicate this with IAR, I can compile and load the app onto the board, and begin execution, but the app crashes when it hits the line:

err_code = sd_softdevice_enable(clock_source, softdevice_assertion_handler);

in softdevice_handler.c.

Digging deeper by tracing through the disassembly, I see that this is a wrapper for calling the SVC interrupt with index 0x10. As soon as this occurs, I get a Hard Fault exception.

I have verified by checking the .map file that my interrupt vectors are being placed at 0x16000, the same as the Keil compiler version.

Does anyone have any clue as to what I may have missed? I can provide a ZIP of the project files if necessary and allowed.

Thanks in advance, Jeff.

[Jeff Wormsley]

It's very confusing. Working through this in the Keil debugger, I'm not sure how this even works. The vector table at 0x1600 has no service handler for SVC 10, so I have to assume that the vectors aren't remapped at this point and the SD handler must be handling this. There is a vector for this pointing to 0x0751 at the appropriate location, so this must be what is executing under Keil. If I stop Keil, and load IAR, I can examine the SD vector table as well, and see the same handler there as I do for Keil, so I would assume the SVC 10 IRQ would be handled the same there as well. But instead, I get a hard fault that is handled at my applications HardFault handler at 0x1943A. I don't see how that can be, as I haven't remapped the interrupt vectors from their default. The .icf file does set the .intvecstart to 0x16000, but this should only control where the interrupts are placed in the memory map. I've built bootloaders with applications on STM32, and had to explicitly set the CPU registers to move the interrupt vector. I would assume the same is needed here. Is it possible some of the startup code is doing this behind my back?