How do I prevent CodeWarrior from stopping after hard reset occurs?

[thomasclark]

I have flashed my program onto a kinetis k10 and I use the debugger to attach to the running program.

Another program running on the PC is capable of resetting my target hardware, but I do not want CodeWarrior to stop when that happens, because it prevents the program running on the PC from getting the expected response.

I have used CodeSourcery before.  The debugger is gdb based and I used the following line in the .gdbinit file to prevent the debugger from stopping after reset:

handle SIGTRAP nostop

Is there anything similar in CodeWarrior?  Why should CodeWarrior always stop after a reset?

Thanks,

Tom

[ZhangJennie]

please move your question to Codewarrior discussion block. thus freescale CW team can check it. thanks, ZhangJun

[thomasclark]

Thanks for the suggestion.  Hopefully, moving to CodeWarrior for MCU groupl, will get me some responses.  There is no breakpoint set, on the first instruction.  CodeWarrior just stops automatically on the first instruction after hard-reset.  Does anyone know how to avoid this?

The flow is like this:

My target hardware powers up and does whatever it does after powerup.

I attach" to the target via debugger.

PC program talks through usb to a chip that pulses the k10 reset low.
After reset happens code warrior stops the target.

PC doesn't receive the expected packet becasue the target is halted.

I want the debugger to let the target continue running after reset.  Later on I want to be able to set breakpoints or manually pause execution to observe memory and registers.

As I mentioned before, using the Code Sourcery tools, I was able to avoid the affect of hard-reset by editting the .gdbinit file.  Are there any customizable settings that  can allow CodeWarrior to continue after hard-reset?

I appreciate any clues that I can receive, even if it is simply to tell me that what I am trying to do is not possible with these tools,

Tom

[Jorge_Gonzalez]

Hello Thomas:

I have investigated and doing some tests. It seems that the behavior you mention is not possible with CodeWarrior, it always stops when resetting the device.

If I get some new information or a workaround I will let you know.

Regards!

Jorge Gonzalez

[thomasclark · Accepted solution]

Jorge,

I believe that I finally stumbled on the answer that I was looking for. 

In the documentation under Common Manuals - Code Warrior Common Features Guide -Debugger - Multicore Reset there is a checkbox called "Run out of reset" which seems to be unchecked by default.  I found that by checking the box, I can get the behavior I want.  I think it works, but I haven't gone back to trying to debug the issue that I was dealing with a few months ago.  I did verify that I can now press the reset button, without the debugger automatically stopping.

To get to the "Run out of reset" checkbox choose Window - Show View - Remote Systems

Then choose <your_project> Target and right click then select properties.  check the checkbox "Run out of reset"

After making this change, use the debugger to "attach" to a processor that is running on the target.  In my case I can use Run->suspend to see that the processor is running. Then Run->Resume.  Then I press the reset button on my board.  It resets without the debugger halting.  In the system I was debugging before, the halting by the debugger prevented the target from replying to another processor before a timeout occurred.  So I think this will fix it.  I'm not ready right now to go back and fully test this, but when I do I will provide confirmation here.

One other note, initially after checking the "Run out of reset" box, after pressing my reset button, I would get a dialog box telling me that the debugger was disconnected (or something to that effect). I checked a checkbox saying reconnect, and another checkbox saying "always do this", and now the dialog box does not pop up.  I press reset and the code continues to run.

Review of why this will help me:

I have a PC program which communicates to the kinetis k10 via a uart.  An FTDI usb to uart chip is used for this.  The FTDI chip has a gpio pin which is attached to the k10's reset.  Effectively the PC can reset the k10 anytime it wants to.  The fact that when debugging, a reset of the k10 would cause ithe k10 halt, prevented me from making much progress.  Under normal behavior the k10 would produce a particular packet on the uart after being reset.  But when the debugger is attached, the k10 would halt on reset, and the PC would timeout because it didn't receive the packet in time.  Possibly another fix could have been to alter the PC to use an infinite timeout here when debugging.

Regards,

Tom