Starting code with IAR

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Starting code with IAR

ソリューションへジャンプ
1,868件の閲覧回数
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 解決策
863件の閲覧回数
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 返答(返信)
864件の閲覧回数
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 件の賞賛
863件の閲覧回数
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 件の賞賛
863件の閲覧回数
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 件の賞賛
863件の閲覧回数
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 件の賞賛