S310 IAR will not debug with RTC1 interrupt active

RE: S310 IAR will not debug with RTC1 interrupt active

Jason Long — Wed, 11 Apr 2018 12:23:29 GMT

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

RE: S310 IAR will not debug with RTC1 interrupt active

Håkon Alseth — Wed, 11 Apr 2018 11:00:01 GMT

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

RE: S310 IAR will not debug with RTC1 interrupt active

Jason Long — Wed, 11 Apr 2018 02:17:43 GMT

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!

RE: S310 IAR will not debug with RTC1 interrupt active

Håkon Alseth — Tue, 10 Apr 2018 11:50:56 GMT

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?

devzone.nordicsemi.com/.../exec.mac

Cheers,

Håkon

RE: S310 IAR will not debug with RTC1 interrupt active

Jason Long — Mon, 09 Apr 2018 11:01:16 GMT

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.

RE: S310 IAR will not debug with RTC1 interrupt active

Jason Long — Mon, 09 Apr 2018 04:54:00 GMT

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

RE: S310 IAR will not debug with RTC1 interrupt active

Håkon Alseth — Fri, 06 Apr 2018 12:21:08 GMT

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