source level debugging with CW HC12 and S12XDP512

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

source level debugging with CW HC12 and S12XDP512

ソリューションへジャンプ
2,377件の閲覧回数
Andi
Contributor II
Hi all,

I have a little problem with the codewarrior debugger. If I press F10 (step over) the debugger goes one line further on the assembler listing level, not the source level. This should be the case only if I press Ctrl+F10. Has anybody an idea, what the problem could be? At the moment I'm not able to debug on source code level.

CW 30days evaluation version 5.7.0
Target: MC9S12XDP512 (I don't use XGATE)
P&E Multilink USB

Thanks, Andy

J2MEJediMaster added required  CW type and info to header


Message Edited by J2MEJediMaster on 2007-04-24 10:06 AM

ラベル(1)
タグ(1)
0 件の賞賛
返信
1 解決策
839件の閲覧回数
Andi
Contributor II
Hi Daniel,

I tried again this morning, and couldn't reproduce it! I have no idea, why it didn't work last time. As far as I remember, last time I ended up in the Assembler code with a very large series of BGND commands - I couldn't get out of there anymore.

Yes, the software always behaved the same if I pressed F10 or the Step Over menu button - no difference.

Finally I found the optimization settings - no optimizations are set, so this shouldn't be the problem.

Anyway, I can debug it now.
Thanks for your suggestions.

Andi

元の投稿で解決策を見る

0 件の賞賛
返信
4 返答(返信)
839件の閲覧回数
CompilerGuru
NXP Employee
NXP Employee
Does it everywhere behave like this, or just at some places?
You are stepping on plain C code? For (inline) assembly, source statements pretty much correspond to assembly instructions.
Do you have samples? Does it show the source code?
Do the toolbar buttons behave better/different?

Daniel
0 件の賞賛
返信
839件の閲覧回数
Andi
Contributor II
Hi Daniel,

When i press the reset button in the debugger, the cursor jumps to the first line of the following code (Cpu.c). These few lines of c-code I can step through with F10 on source code level (even though I think it's pretty much 1:1 to assembler).

/* ### MC9S12XDP512_112 "Cpu" init code ... */
 /*  PE initialization code after reset */
 /* ECLKCTL: NECLK=0,NCLKX2=1,??=0,??=0,??=0,??=0,EDIV1=0,EDIV0=0 */
 setReg8(ECLKCTL, 64);                
 /* MMCCTL1: ??=0,??=0,??=0,??=0,??=0,EROMON=0,ROMHM=0,ROMON=1 */
 setReg8(MMCCTL1, 1);                 
 /* DIRECT: DP15=0,DP14=0,DP13=0,DP12=0,DP11=0,DP10=0,DP9=0,DP8=0 */
 setReg8(DIRECT, 0);                  
 /* IVBR: IVB_ADDR=255 */
 setReg8(IVBR, 255);                  
 /*  System clock initialization */
 /* CLKSEL: PLLSEL=0,PSTP=0,??=0,??=0,PLLWAI=0,??=0,RTIWAI=0,COPWAI=0 */
 setReg8(CLKSEL, 0);                  /* Select clock source from XTAL and set bits in CLKSEL reg. */
 /* PLLCTL: CME=1,PLLON=0,AUTO=1,ACQ=1,FSTWKP=0,PRE=0,PCE=0,SCME=1 */
 setReg8(PLLCTL, 177);                /* Disable the PLL */
 /*** End of PE initialization code after reset ***/
 __asm("jmp _Startup");               /* Jump to C startup code */

 /* initialize the stack pointer */
  INIT_SP_FROM_STARTUP_DESC(); /*lint !e522 asm code */ /* HLI macro definition in hidef.h */

#ifndef __ONLY_INIT_SP
  Init(); /* zero out, copy down, call constructors */
#endif


Here the main function is entered. The cursoer jumps to the line moduleTestMode = MODULE_TEST_MODE;
After this instruction I cannot go to init_mcu(); by pressing F10. It always goes line by line in the assembler code.

void main(void)  // firmware
{
 uInt08 moduleTestMode;
 uInt32 error;
 
 // modify the test mode here with the debugger
 moduleTestMode = MODULE_TEST_MODE;
 
 //Cpu_DisableInt();
 init_mcu();


Here the rest of the program code follows....

Yes, it's plain c code, no inline.
All the source code is shown in the "Source" window on the left side and the assembler code is shown in a separate window on the right hand side.

What do you mean by "Do the toolbar buttons behave better/different?"?

The strange thing is that I could step into the init_mcu() function (initializes ports and other periphery) by F11 and then every single c code line by F10 as expected. This worked exactly once (the first time i started the debugger). Since then I tried to restart the computer, power cycle the target... several times - I'm not able to do it anymore!

Andi


0 件の賞賛
返信
839件の閲覧回数
CompilerGuru
NXP Employee
NXP Employee
Hmm. I still dont exactly understand what you experience.
Basically you say everything goes as expected until you reach
" moduleTestMode = MODULE_TEST_MODE;"
Does that line generate 2 assembly instructions for you? When you are there and press F10, where do you end? After the first assembly instruction still inside of this statement? Then when you step on, you sooner or later do reach the JSR init_mcu (or CALL init_mcu), right? And then when you press F10, do you step inside init_mcp or to the next statement (as it should)?
When you enable the markes (right context menu over the source window) are they all at statement start positions as they should? Or is this is an issue about debugging in optimized code?
You said you could once step into
init_mcu and now no longer. What does that mean, now you do not reach init_mcu anymore, you always step over it, or do you step into it but it does only do assembly steps?

The remark "Do the toolbar buttons behave better/different?"
was about if this is a keyboard thing or not. When you use the menu or the toolbar to step around, does it behave the same?

Anything else which is special in your setup? Can you reproduce it with a newly created project?

Daniel

0 件の賞賛
返信
840件の閲覧回数
Andi
Contributor II
Hi Daniel,

I tried again this morning, and couldn't reproduce it! I have no idea, why it didn't work last time. As far as I remember, last time I ended up in the Assembler code with a very large series of BGND commands - I couldn't get out of there anymore.

Yes, the software always behaved the same if I pressed F10 or the Step Over menu button - no difference.

Finally I found the optimization settings - no optimizations are set, so this shouldn't be the problem.

Anyway, I can debug it now.
Thanks for your suggestions.

Andi
0 件の賞賛
返信