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]

Hi,

 

There shouldn't be a whitespace between the two "-":

--drv_vector_table_base=0x0

 

Are you setting a breakpoint while the softdevice is running? This will cause an assertion inside the softdevice if you run after hitting a breakpoint, as it's timing will be skewed.

 

Best regards,

Håkon

[Jason Long]

Hi Håkon,

I fought this for another day.

With --drv_vector_table_base=0x0 the debugger starts immediately at 0xfffffffe if "run to main" is on and I can do nothing

Without the --drv_vector_table_base=0x0 the debugger kicks out to 0xfffffffe on the first interrupt (any enabled interrupt, RTC1 or SD event right now).

In both cases, the code works without the debugger.

Same behavior in IAR 7.2 and 8.10 and with J-Link OB with 6.10e and a J-Link EDU v9.3 with J-Link 6.10e and 6.30j dlls.

This is without any breakpoints.  When I run without interrupts enabled, I can halt the debugger once.  If I restart, it is lost and subsequent halts will usually find the program counter in RAM space!

Questions: should "use flash loaders" be on in project options?  Are there different flash loaders than default?  Are there any special project settings that must be set?

FYI I've used IAR and J-Link tools for over a decade, so hopefully that experience is helping and not hindering my exploration... I have limited experience developing specifically on the nRF51s, though.

Today I'll see if I can find an example project from Nordic and see if it works and try an older project that I did on these same boards that worked fine (but with SD 210 just for ANT).  Sorry I'm stuck way back in SDK 6.1 and old SD 310 due to my version 2 nRF51422 hardware.

The project is on Gihub in the "pin_config" branch:

https://github.com/eiefirmware/eiefw3/tree/pin_config

[Jason Long]

I am convinced that the debugger cannot see the vector table at 0x0.  Anything I do that would require the main vector table fails including even JUST trying the reset vector with the --drv_vector_table_base=0x0. All is fine without the debugger.

Just for sanity check, here's a shot of the load from nRFGo Studio

Defeated.

[Håkon Alseth]

Hi,

 

First off, sorry for the delayed answer!

I have been trying to debug your project for a while now, and I am seeing the exact same behavior as you describe.

I'm using IAR v7.80.3.

Tried setting the drv_vector_table_base=0 and =0x20000, and I see the exact same behavior. When set to 0, no chance of debugging, and when set to 0x20000, it will fail at the first interrupt called (end up in 0xFFFFFFE).

I tried debugging the .out file (generated by IAR) with GDB. I did a small alteration by setting the TIMER1 IRQn as pending in main (after softdevice enable), and just added a delay to it instead of a while(1). GDB did not halt at the interrupts, and it looks like that debug session runs as normal.

 

I found this older thread, which indicates that the IAR debugger does not like it when the initial stack pointer and reset vector is unavailable (in this case, readback protected):

https://devzone.nordicsemi.com/f/nordic-q-a/3704/s310-and-iar-i-jet-load-run

 

After creating a .mac file (see attached) and pointing to it in the IAR settings:

Then the debug session started up as normal.

Could you try this and see if it works at your end?

 

exec.mac

 

Cheers,

Håkon

 

[Jason Long]

Yes, yes, yes!!!!!

Thank you for finding that post and solution from Matt Barr (thank you, Matt!).

This is what I get for using old versions of SDs, as Matt's comment on newer SDs not read-protecting makes sense and explains why the rest of the world isn't fighting this with me.

Though I don't understand what the macro file is doing with the debugger (I'll look that up), this definitely feels like the root cause solved.

Awesome, thank you Håkon!

Love you guys at Nordic!