Starting code with IAR

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Starting code with IAR

跳至解决方案
1,817 次查看
lucky06200
Contributor II

Hello World !

I have a code starting with j-trace IAR debug and running correctly

Reset hardware restart correctly program.

When i disconnect debugger (red cross in IDE) it is no more possible to run software.

Same when i disconnect j-trace, reset (hardware) do no start my code.

An idea ?

标签 (1)
标记 (2)
0 项奖励
1 解答
812 次查看
egoodii
Senior Contributor III

There are certainly several options to look into.

First of all, the debugger-interface does not 'bother' to read the actual reset-vector from Flash, since it 'already knows' where to start from.  So the first thing to check is to see if absolute 0 contains a valid stack-pointer preset, and is followed by your proper code entry point (0x411?).

If that looks OK, then the next steps to consider are 'startup time'.  When you run the debugger, the time from 'power up' to 'code start' is 'very long', while using the internal chip power-on-reset the CPU will start running code just over 1.7V.  If you use an external oscillator clock source, for instance, you can be sure that it has to wait 'many milliseconds' after a full 3.3V to get to full oscillation.  Look for issues like this where the CPU may be starting long before something external is really 'ready to go'.

在原帖中查看解决方案

0 项奖励
4 回复数
813 次查看
egoodii
Senior Contributor III

There are certainly several options to look into.

First of all, the debugger-interface does not 'bother' to read the actual reset-vector from Flash, since it 'already knows' where to start from.  So the first thing to check is to see if absolute 0 contains a valid stack-pointer preset, and is followed by your proper code entry point (0x411?).

If that looks OK, then the next steps to consider are 'startup time'.  When you run the debugger, the time from 'power up' to 'code start' is 'very long', while using the internal chip power-on-reset the CPU will start running code just over 1.7V.  If you use an external oscillator clock source, for instance, you can be sure that it has to wait 'many milliseconds' after a full 3.3V to get to full oscillation.  Look for issues like this where the CPU may be starting long before something external is really 'ready to go'.

0 项奖励
812 次查看
lucky06200
Contributor II

In fact, my application is a little more complicated.

I have 2 MQX application running on the same kinetis, but not together.

One is flashed @0x00000000 and second @0x00041000 (first and second half of internal flash memory).

First application is a boot-loader running from start of ROM and use as loader/application updater/maintenance code.

Second is my real application (analog data measurement).

When request in first code (automatically, command line or cgi script) we invalidate interrupt, get SP and PC from second application, and call it. This work very well with j-trace connected (in all mode of use).

As soon as i disconnect debugger ("Stop debugging" red cross button in IAR IDE) going from loader to second application do not work anymore. And i have no more debugger to understand what appends!

Note: second application, linked at adresse 0x00000000 work without any problem.

Any idea/suggestion? Where can i look? What can i do?

0 项奖励
812 次查看
egoodii
Senior Contributor III

Is there a 'change' in clocking strategy between the two 'applications'?  I assume the Interrupt Vector Table (and pointer thereto) handoff is expected to be OK, and not 're-enabled' until that (and all the NVIC registers that individually enable them) are all valid again.  I'm trying to think of things where 'time since power-up (or last interrupt)' would directly affect the 'run-ability' of the second app.

0 项奖励
812 次查看
lucky06200
Contributor II

I have found the reason.

In my code, after invalidate interrupt, there were a printf to display function call.

But printf do no work if interrupt not functioning, and wait for them ...

Now, my code without printf work correctly..

0 项奖励