Updated 15/05/2013.... After further testing, I've corrected the problem description and changed the post title from ".... single step debugging issue" to "...stuck on break point issue" to more reflect the problem, there is a work around..see below.
I have a trial of Code Warrior 10.3 for the Power Architecture (Not MCU) for windows and am trying to get the USB Tap debugger to work correctly.
The processor is a QorIQ P1025 on a TWR-P1025 development board running the MQX RTOS.
The issue is as follows: -
I can single step through the code during kernel initialisation, but went the operating system is started, I cannot single step through my application code? However, break points work, local, global variables report correctly. To get passed a break point I must first disable it, then press run?.
During kernel initialisation I can run to break points, step over break points, select resume etc all seems to work okay.
After MQX kernel initialisation i.e. running my application code, now when I hit a break point, I cannot step over, step into, or select resume, the debugger stays on the same line. However, if I disable or remove the break point, I can step over, step into and select the resume functions.
So disabling the break point is a work around.
I’ve gone through and modded the emulator *.tcl file, disable parts in kernel initialisation but no joy.
This thread https://community.freescale.com/thread/303172, even though it’s for MCU version of code warrior did imply that version 10.2 may work? I’ll summit a support request and try and get an old version but.......
I've tried version 10.2, this makes no difference
Any ideas / pointers / oversights would be very welcome?
Thanks
Message was edited by: rick101
解決済! 解決策の投稿を見る。
Yes it is the same problem that you have... But freescale are working on it
"A option of "disable interrupt while stepping" is needed in the debugger configuration like CodeWarrior for MCU, but it has not been fixed in CodeWarrior for PA 10.3, the development team is working on it.
Single-stepping never ends up at the interrupt vector, instead it appears to be an execution problem, causing the SRR0/SRR1 values not to be updated when hitting the second breakpoint (thus maintaining the values from the first breakpoint hit and causing execution to "return" there, which makes it look like we are unable to resume from the breakpoint, when in fact we are re-executing the code between the two breakpoints)
We are investigating this further. In the mean time, I noticed three things that can be used to work-around the issue:
- after hitting any breakpoint, set SRR0 and SRR1 to 0x0 (either from the Register View, or from the Debugger Shell)
- after hitting any brekpoint, remove it before attempting to resume execution
- debug with MSR[EE] disabled"
Corrected my initial post, now have a work around
I am not clear if my problem is the same, but I have a problem with single stepping through debug as well. The program immediately jumps to an interrupt, and there doesn't seem to be any ability to turn them off automatically when running.
This happens with two separate Power PC Processors, and sad to say it with CodeWarrior 5.7, 10.0, 10.1, 10.2, and 10.3
10.3 Did improve on 10.2. You can now execute after setting a break point, before you would immediate jump back to the same break point you just stopped at.
I hope you get a response I would love a fix on this as well
Yes it is the same problem that you have... But freescale are working on it
"A option of "disable interrupt while stepping" is needed in the debugger configuration like CodeWarrior for MCU, but it has not been fixed in CodeWarrior for PA 10.3, the development team is working on it.
Single-stepping never ends up at the interrupt vector, instead it appears to be an execution problem, causing the SRR0/SRR1 values not to be updated when hitting the second breakpoint (thus maintaining the values from the first breakpoint hit and causing execution to "return" there, which makes it look like we are unable to resume from the breakpoint, when in fact we are re-executing the code between the two breakpoints)
We are investigating this further. In the mean time, I noticed three things that can be used to work-around the issue:
- after hitting any breakpoint, set SRR0 and SRR1 to 0x0 (either from the Register View, or from the Debugger Shell)
- after hitting any brekpoint, remove it before attempting to resume execution
- debug with MSR[EE] disabled"