topic Re: FRDM-KE02Z debug peculiarity in Kinetis Microcontrollers

FRDM-KE02Z debug peculiarity

davetelling — Fri, 21 Nov 2014 17:21:54 GMT

Has this been happening to anyone else? I have a FRDM-KE02 board which I'm using to learn some ARM core basics, and I have found an odd behavior when debugging, using the P&E Micro USB interface.

I have a short program that sets up a timer and captures rising edge interrupts. I've been having a lot of trouble debugging, because it seems that, despite the fact that as far as I can tell, the program is correct, when I go to debug, the system gets caught in some kind of loop where it constantly hits the interrupt function.

In trying to figure out what is going on, I found that making any change in the program, even adding a comment line, could cause this behavior. I subsequently found that if I went back and forth between the IDE and the debugger, eventually I could start the debugger and it would work properly, WITHOUT ANY PROGRAM CHANGES!

Has this happened to anyone else? Optimizations are set to "none".

Re: FRDM-KE02Z debug peculiarity

egoodii — Fri, 21 Nov 2014 17:58:07 GMT

You don't describe exactly how you are running the debugger, but I will just point out that the ARM 'debug' interface access cycles are not 'special reads', which means that any read from the debugger is just like a read by the processor, so ANY read that has a 'side effect', which might include clearing a 'status available' flag, or 'popping' a FIFO, etc., WILL get triggered by such a read if the debugger EVER attempts to read (to display) a set of peripheral registers or the memory-address-area containing them. The bottom line is that you CANNOT, in general, 'step thru' low-level peripheral-access code and 'watch' how it interacts with the peripheral registers.

Re: FRDM-KE02Z debug peculiarity

davetelling — Fri, 21 Nov 2014 18:22:03 GMT

Hello Earl,

Actually, I'm just clicking the "Make-Start Debugger" button in the IAR IDE, and once it stabilizes, clicking the "run" button. I have a simple program that captures a rising edge, using FTM2, and toggles PTA0. When the debugger is "misbehaving" I can click the run button, and no output on PTA0. If I click the "halt" button, it will invariably be hung in the isr for the capture interrupt in the "ftm.c" file. If I click the single-step button, it will continue to run (i.e. not single step) and if I click "halt" again, it will stop at the FTM_isr function in ftm.c. I can then exit the debugger, re-make (or redo the make/debug process) and eventually (this last time, it took about 10 tries) it will run normally.

I'm not trying to single-step, just flash and run.

The only thing I notice is that, during the startup of the debugger, there is a warning:

Fri Nov 21, 2014 10:17:47: Skipping flash loading pass because there is no data in the designated range: 0x10000000-0x100000FF. I get this warning every single time.

I don't know if this is an IAR EWB problem or a P&E debugger interface problem, but it is terribly annoying, because I don't know if any problems I have are of my own ineptitude, or a development software/hardware problem.

Re: FRDM-KE02Z debug peculiarity

Hui_Ma — Mon, 24 Nov 2014 08:28:41 GMT

Hi Dave,

I don't meet your mentioned issue with FRDM-KE02Z board.

If you set the correct MKE02 device at IAR project options with below picture?

What is the IAR version you are using?

If it is possible, if you could post your project and I could test on my site?

Wish it helps.
best regards
Ma Hui

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: FRDM-KE02Z debug peculiarity

davetelling — Mon, 24 Nov 2014 15:21:47 GMT

Hui_Ma,

Yes, I am selecting the correct processor in the project options. I am using the latest EWB version from the IAR website, 7.3. I have another FRDM board that I am going to try today and see if it makes any difference. So far, this only seems to happen with projects that use the timers. I will post my results.

Thank you,

Dave Telling