Kinetis - START_FROM_RESET

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Kinetis - START_FROM_RESET

Jump to solution
726 Views
JHinkle
Senior Contributor I

The following comment appears in my startup.s file

* STARTUP_FROM_RESET
*
* If defined, the program will startup from power-on/reset. If not defined
* the program will just loop endlessly from power-on/reset.
*
* This definition is not defined by default on this target because the
* debugger is unable to reset this target and maintain control of it over the
* JTAG interface. The advantage of doing this is that it allows the debugger
* to reset the CPU and run programs from a known reset CPU state on each run.
* It also acts as a safety net if you accidently download a program in FLASH
* that crashes and prevents the debugger from taking control over JTAG
* rendering the target unusable over JTAG. The obvious disadvantage of doing
* this is that your application will not startup without the debugger.
*
* We advise that on this target you keep STARTUP_FROM_RESET undefined whilst
* you are developing and only define STARTUP_FROM_RESET when development is
* complete.

All my work to date has been having the device connected to a JLink.

I now am getting ready to run the device without a JLink connection.  

The comment above says that is STARTUP_FROM_RESET is not defined - the cpu goes into an endless loop so that "a debugger" can connect to it.

Is this a "general" statement or does it NOT apply to a JLink connected device?

Segger has no information that states this "endless loop" debug mode is required for them to get a hold of the cpu.

Is the statement for NON-JLink debug devices?

Thanks for any clarification.

Joe

0 Kudos
1 Solution
607 Views
mjbcswitzerland
Specialist V

Hi Joe

I have worked with over 80 Kinetis types during 6 years and with about 8 different JTAG/SWD interfaces, as well as several J-Link models (and most available IDEs). Never have I needed to use the technique of not installing a normal reset vector; during development it is not advisable to test code that doesn't represent the final state (because there are sometimes nasty surprises when changed).


There are other techniques used by the debuggers and IDEs to take over control of the chip in an emergency (like the setting to immediately do a chip erase on connection).


In any case I would immediately move to the final state of code and ignore this method.

Regards

Mark

Kinetis for professionals: http://http://www.utasker.com/kinetis.html

View solution in original post

0 Kudos
3 Replies
608 Views
mjbcswitzerland
Specialist V

Hi Joe

I have worked with over 80 Kinetis types during 6 years and with about 8 different JTAG/SWD interfaces, as well as several J-Link models (and most available IDEs). Never have I needed to use the technique of not installing a normal reset vector; during development it is not advisable to test code that doesn't represent the final state (because there are sometimes nasty surprises when changed).


There are other techniques used by the debuggers and IDEs to take over control of the chip in an emergency (like the setting to immediately do a chip erase on connection).


In any case I would immediately move to the final state of code and ignore this method.

Regards

Mark

Kinetis for professionals: http://http://www.utasker.com/kinetis.html

0 Kudos
607 Views
JHinkle
Senior Contributor I

I totally agree.  THAT is why I asked the question.

It's part of the startup.s code provided by Rowley for Kinetis.  Just wondering WHY?

0 Kudos
607 Views
mjbcswitzerland
Specialist V

Joe

Ask Paul at Rowley - he'll be able to tell you.

I have used Crossworks with normal reset vector without any difficulties.

Regards

Mark

0 Kudos