Hey guys,
I'm using oZone 2.56l on a Nordic nRF52832 connected by a J-Link Plus. Toolchain: IAR 8.11.2. I have two problems with this configuration lately:
1. On loading the generated .out file, I get messages from oZone:
It still loads the objectfile correctly though, debug information as far as I can tell seems to be correct and it stops at main as I expect it to.
2. When running, the target stops somewhere in Nordic's softdevice, always on the same address and it won't continue from there. It didn't to do that a couple of oZone versions ago and it doesn't do that when using IAR's debugger either. There seems to be no reason to stop here whatsoever: no breakpoint set, no weird exception or anything. The instruction it stops on is a pretty simple LDR R3, [R3+0x0C] where R3 points on an address ending in 0x00 (so no alignment problems either). No memory protection.
I'm lost. The reason I use oZone instead of IAR's debugger is its convenient RTT implementation and it provides better trace support when using our J-Trace Pro probe. I feel somewhat disabled using IAR's debugger, so if this can be fixed I would be very grateful.
Edit: could it be this is the same problem as described here => [SOLVED] Ozone: v2.56 regression with Nordic SoftDevice (S140, nRF52840) ?
Looks like it... the vector table lives not where oZone expects it to be!
I'm using oZone 2.56l on a Nordic nRF52832 connected by a J-Link Plus. Toolchain: IAR 8.11.2. I have two problems with this configuration lately:
1. On loading the generated .out file, I get messages from oZone:
It still loads the objectfile correctly though, debug information as far as I can tell seems to be correct and it stops at main as I expect it to.
2. When running, the target stops somewhere in Nordic's softdevice, always on the same address and it won't continue from there. It didn't to do that a couple of oZone versions ago and it doesn't do that when using IAR's debugger either. There seems to be no reason to stop here whatsoever: no breakpoint set, no weird exception or anything. The instruction it stops on is a pretty simple LDR R3, [R3+0x0C] where R3 points on an address ending in 0x00 (so no alignment problems either). No memory protection.
I'm lost. The reason I use oZone instead of IAR's debugger is its convenient RTT implementation and it provides better trace support when using our J-Trace Pro probe. I feel somewhat disabled using IAR's debugger, so if this can be fixed I would be very grateful.
Edit: could it be this is the same problem as described here => [SOLVED] Ozone: v2.56 regression with Nordic SoftDevice (S140, nRF52840) ?
Looks like it... the vector table lives not where oZone expects it to be!
The post was edited 2 times, last by jev ().