S310 IAR will not debug with RTC1 interrupt active

[Jason Long]

It seems like a similar IAR debugging problem has been solved but after a day of trying everything...

BLE application with SDK 6.1 and SD 310 1.0 running IAR 8.1 (and identical issue for IAR 7.20).  J-Link 9.3 with 6.30j firmware.

- -drv_vector_table_base=0x0 is in Debugger extra options (is the spacing "- -drv" correct?)

Loading and running without debugger on the board works.

If debugging, the debugger kicks out as soon as the first RTC1 interrupt fires and shows the PC stuck at the 0xfffffffe address.

If I don't enable the RTC interrupt, code debugs generally fine.

.icf is good I think: 

/* Softdevice S310 1.0 (51422 rev. DA and E0) */
define symbol __ICFEDIT_intvec_start__ = 0x00020000;
define symbol __ICFEDIT_region_ROM_start__ = 0x00020000;
define symbol __ICFEDIT_region_ROM_end__ = 0x0003FFFF;

define symbol __ICFEDIT_region_RAM_start__ = 0x20002400;
define symbol __ICFEDIT_region_RAM_end__ = 0x20003FFF;

I've checked the .map for anything that looks weird and even verified the vector table by inspection in the Disassembly window after flashing.

Thoughts?

Thank you!

[Håkon Alseth]

Always happy to help. All credit goes to Matt Barr!

The .mac file states where the initial stack pointer and the Reset_Handler of the S310 is located, which is normally fetched by reading address 0 (initial_sp) and address 4 (reset_handler).

 

Cheers,

Håkon

[Jason Long]

Ok, thanks.

As an update for the record and to help others: I have now tried this work-around on IAR 7.2 and 8.10 both with a J-Link OB and J-Link EDU both running JLinkARM.dll 6.10e.  I have experimented with various modes of operation to see how everything works:

- Including or removing --drv_vector_table_base=0x0

- Enabling and or not enabling the soft device

- Enabling or not enabling application interrupts

I can get the debugging I need with various combinations of the above, but not everything works with all combinations.  For example, using IAR "reset" does not work when --drv is in place.  The debugger gets lost in the same way (I assume the .mac file is not referenced in this case).  Restarting after a breakpoint in the application code can also lead to a PC lost in RAM somewhere after the code is restarted.  But overall, it's workable and still my fault for using an old SD.

Cheers,
Jason