none
NK(操作系统)的入口函数或第一条代码在什么位置? RRS feed

  • 问题

  •  

    请问,在 WINCE5.0 下,

    Bootloader 运行起NK(操作系统), NK(操作系统)的入口函数或第一条代码在什么位置? 谢谢.

     

    2008年2月28日 10:20

答案

  •  

    你的断点可以设置在第一个被加载的驱动的初始化函数中。你的提示信息表示你的KITL在建立连接的时候超时了,所以就不能Debug了。这个时候你的串口应该有打印信息,通过打印信息你应该能够看到KITL是否连接成功。如果没有成功,就说明你的KITL有问题。
    2008年3月3日 8:10

全部回复

  •  config.bib决定了入口点的位置,如果您的bootloader找不到config.bib请确保您的镜像是否正确完整的下载

     

    希望对您有帮助

     

    Regards ~

    2008年2月28日 17:09
    版主
  •  

    Bootloader 运行起wince5.0(操作系统).

    我的意思是wince操作系统软件的入口函数或第一条代码在什么位置? 我想代码断点跟踪.

    2008年2月29日 1:31
  • wince5.0操作系统软件的入口函数或第一条代码是汇编,   我想找在这之后的C或C++代码.

     

    我想用PB进行一些驱动的代码断点跟踪.谢谢.

     

    2008年2月29日 3:20
  • 在WinCE5.0中,NK最开始是从OAL层中的startup.s中执行的,里面都是汇编写的。然后会调用KernelStart,KernelStart会调用OEMInit()函数来对板子做一些基本的初始化工作。你可以看看OAL中的的OEMInit()函数。

     

    你要想跟踪你的驱动程序,就应该在你的驱动里面设置断点,当WinCE加载了你的驱动的时候,就会停在断点处了。

     

    2008年2月29日 4:25
  •  

    ARM-WinCE 大哥 辛苦了.

     

    我看PB 调试 WinCE SHELL 的代码比较方便(代码断点跟踪调试)。

    调试象NandFlash, LCD这样的驱动,PB 代码断点跟踪调试 用起来方不方便?

    在驱动里面设置断点,当WinCE加载驱动的时候,会停下来,但不会停在断点处。

    2008年2月29日 6:52
  •  

    从你的描述来看,我觉得有两种可能。一是你的代码和你的驱动不对应,还有一种可能就是在WinCE启动后,按顺序加载驱动,可能还没有执行到你设置断点的地方,就已经因为错误或者其他原因停下来了。

     

    对于驱动来说,你可以在这个驱动的初始化函数的开始设置断点,只要这个驱动被加载了,就应该可以停下来的。

    2008年2月29日 7:38
  • ARM-WinCE大哥辛苦了.

    Debug调试状态时,有二个对话框出现

    1. 对话框1   UnMapped Source file
                 UnMapped Source file  detected while trying to set breakpoint

    2. 对话框2   Connect failure to device CE device
                 The debugger KITL packet receive has timed out. Do you wish to retry?
     

    不知为何原因?

     

    ////////////

    //////PB代码流程


    C:\WINCE500\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\mdarm.c   -----> void ARMInit(int cpuType,
     int abSp, int iSp,  int uSp, PPTE pOEMAddressTable)

    C:\WINCE500\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\mdarm.c(496):    OEMInit(); 
    C:\WINCE500\PUBLIC\COMMON\OAK\CSP\ARM\CENTRALITY\AT4X0A\SRC\KERNEL\KERNLIBS\INIT\init.c(47):void OEMInit()

     

    ARMInit() ---> OEMInit() -->

                            {
                               ////release 版从这里经过
                               ////debug 版 我在这里设断点。不会跳到断点,但已点亮LED
                               OEMWriteDebugLED(1, 0x0A);   //点亮LED
                            OEMWriteDebugLED(2, 0x0B);   //点亮LED
                            }


    //////CEPB 设置

    CEPB--->platform settings

    Enable Full Kernel Mode      选择
    Enable Kernel Debugger       选择
    Enable KITL                  选择
     

     


     

    2008年3月1日 4:21
  • 你在这里不能设置断点。这是OEMInit(),通常用于初始化系统中最基本的硬件。KITL应该在它里面被初始化的,之后会建立KITL连接,只有KITL连接建立以后,你才能在你的驱动里面设置断点,调试你的代码。

     

    从你描述的现象看,你的KITL连接好像没有建立起来,问题可能出在这里。

     

    还有,我说的不一定对,别老大哥大哥的,受不了。

    2008年3月3日 3:19
  •  

    请问, ARM CPU KITL断点调试跟踪wince, 断点最前的位置应设在什么地方设置?

    直接在驱动中加断点,会有 "The debugger KITL packet receive has timed out. Do you wish to retry? " 提示.

    2008年3月3日 6:40
  •  

    你的断点可以设置在第一个被加载的驱动的初始化函数中。你的提示信息表示你的KITL在建立连接的时候超时了,所以就不能Debug了。这个时候你的串口应该有打印信息,通过打印信息你应该能够看到KITL是否连接成功。如果没有成功,就说明你的KITL有问题。
    2008年3月3日 8:10
  • 是KITL有问题。我不设断点,调试时,代码总是在 \PRIVATE\WINCEOS\COREOS\NK\KITL\edbgprot.c 中循环.  我该如何是好?

     

     

     

    调试时有串口信息打出.

    /////
    KITL Creating IST-
    KITL Interrupt thread started (hTh: 0x2FFCBFDA, pTh: 0x8FFC9000), using SYSINTR000hntrality NBOOT v5.0                                                       

     

    在wince shell中设断点,能运行到断点处并停下.

    串口信息:

    KITL: Leaving polling mode...
    KITL Checking client registrations
    +RegisterClientPart2: Id 0x00000000
    KITL Timer thread started, (hTh: 0x0FFDBFCE, pTh: 0x8FFCB400)
    -RegisterClientPart2
    +RegisterClientPart2: Id 0x00000001
    -RegisterClientPart2
    KITL Creating IST
    KITL Interrupt thread started (hTh: 0x8FFCBFDA, pTh: 0x8FFC9000), using SYSINTR
    30
    Enabling adapter ints...
    VBridge:: VB_INITIALIZED returns [1]
    VBridge:: RESET_BUFFER received.
    VBridge:: built on [Mar  1 2008] time [21:51:38]
    VBridgeInit()...TX = [16384] bytes -- Rx = [16384] bytes
    Tx buffer [0xAD5038E0] to [0xAD5078E0].
    Rx buffer [0xAD507900] to [0xAD50B900].
    Ne2kDbg:: MulticastRegs set to : 0-0-0-0-0-0-0-0
    NE2KDBG:: Set Ndis filter [0xB] -> [0xC]
    VBridge:: Current VMini packet filter = [0xB]

     

    2008年3月3日 9:09
  •  

    一般KITL有问题,和网卡的驱动关系比较大。你可能要花点时间看看代码,如果调试,你可以在代码里面加一些打印信息,通过串口的打印信息来分析问题。看看是网卡驱动造成的,还是有其他的原因。
    2008年3月5日 2:25
  • 是KITL的问题。如果你的KITL是基于ethernet的,需要看一下你的系统中的ethdbg的驱动是否有问题。在Kernel Debugger启动之前,是不能够设置断点调试系统的,所以调试第一行代码肯定是不行了。而CE上的Kernel debugger又是依赖kITL的,所以把KITL的以太网驱动修好才是第一步。Smile

    2008年3月5日 11:45
    版主