Windows Embedded CE6

System iMx31 128 mb RAM (custom platform)

Ethernet BOOT



Image has a standard Shell and use ObjectStore.



Kitl enabled on Ethernet



When I try a retail image (also kitl enabled on Ethernet), it works
perfectly but the same image in debug mode stop after:

"Windows CE KernelInit".



I check inside OALTimerIntrHandler function and strangly, CurMSec is
initialize with a large value: 0xFFFCF2C0 (in RETAIL this value is 0).

Because of this:

// partial code.

// Reschedule?

if ((int)(CurMSec - dwReschedTime) >= 0) sysIntr = SYSINTR_RESCHED;



sysIntr is nerver set to SYSINTR_RESCHED.



I try to initialize CurMSec earlier in OemInit and after this sysIntr is set
to SYSINTR_RESCHED.

But the system Hangs anyway.



It's like there some corruption in kernel globals.



Anyone has an idea on where I have to look.



Regards

Re: Problem in debug mode CE6 by Dean

Dean
Wed Feb 06 06:25:59 PST 2008

CurMSec is intentionally set to that value in debug. It provides a
mechanism to test your tick implementation when that variable is about to
roll over. Remember that it will eventually reach that value in retail mode
too, so your tick implementation must be able to handle it.

In this case, that's not likely your problem. You're not getting nearly far
enough to even have the tick timer running. More likely, you've got a
problem with your memory map in debug mode. One possibility is that your
image is too big (debug images are far larger than retail). If that
happened you could have an image that wasn't complete and could fail.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
news:ejnEomMaIHA.600@TK2MSFTNGP02.phx.gbl...
> Windows Embedded CE6
>
> System iMx31 128 mb RAM (custom platform)
>
> Ethernet BOOT
>
>
>
> Image has a standard Shell and use ObjectStore.
>
>
>
> Kitl enabled on Ethernet
>
>
>
> When I try a retail image (also kitl enabled on Ethernet), it works
> perfectly but the same image in debug mode stop after:
>
> "Windows CE KernelInit".
>
>
>
> I check inside OALTimerIntrHandler function and strangly, CurMSec is
> initialize with a large value: 0xFFFCF2C0 (in RETAIL this value is 0).
>
> Because of this:
>
> // partial code.
>
> // Reschedule?
>
> if ((int)(CurMSec - dwReschedTime) >= 0) sysIntr = SYSINTR_RESCHED;
>
>
>
> sysIntr is nerver set to SYSINTR_RESCHED.
>
>
>
> I try to initialize CurMSec earlier in OemInit and after this sysIntr is
> set to SYSINTR_RESCHED.
>
> But the system Hangs anyway.
>
>
>
> It's like there some corruption in kernel globals.
>
>
>
> Anyone has an idea on where I have to look.
>
>
>
> Regards
>



Re: Problem in debug mode CE6 by fd

fd
Wed Feb 06 07:18:03 PST 2008

Thank you for this precision

My DEBUG image size is 24 mb. (11 MB in RETAIL).

I have no problem at all in RETAIL even large image (24 mb or more in
RETAIL).
With more DEBUG trace enabled (0xffff mask), my system died somwhere in
KernelInit() / InitMemoryPool() / OEMCacheRangeFlush()!!!

Regards.

"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:%23$oqbvMaIHA.1960@TK2MSFTNGP02.phx.gbl...
> CurMSec is intentionally set to that value in debug. It provides a
> mechanism to test your tick implementation when that variable is about to
> roll over. Remember that it will eventually reach that value in retail
> mode too, so your tick implementation must be able to handle it.
>
> In this case, that's not likely your problem. You're not getting nearly
> far enough to even have the tick timer running. More likely, you've got a
> problem with your memory map in debug mode. One possibility is that your
> image is too big (debug images are far larger than retail). If that
> happened you could have an image that wasn't complete and could fail.
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
> "fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
> news:ejnEomMaIHA.600@TK2MSFTNGP02.phx.gbl...
>> Windows Embedded CE6
>>
>> System iMx31 128 mb RAM (custom platform)
>>
>> Ethernet BOOT
>>
>>
>>
>> Image has a standard Shell and use ObjectStore.
>>
>>
>>
>> Kitl enabled on Ethernet
>>
>>
>>
>> When I try a retail image (also kitl enabled on Ethernet), it works
>> perfectly but the same image in debug mode stop after:
>>
>> "Windows CE KernelInit".
>>
>>
>>
>> I check inside OALTimerIntrHandler function and strangly, CurMSec is
>> initialize with a large value: 0xFFFCF2C0 (in RETAIL this value is 0).
>>
>> Because of this:
>>
>> // partial code.
>>
>> // Reschedule?
>>
>> if ((int)(CurMSec - dwReschedTime) >= 0) sysIntr = SYSINTR_RESCHED;
>>
>>
>>
>> sysIntr is nerver set to SYSINTR_RESCHED.
>>
>>
>>
>> I try to initialize CurMSec earlier in OemInit and after this sysIntr is
>> set to SYSINTR_RESCHED.
>>
>> But the system Hangs anyway.
>>
>>
>>
>> It's like there some corruption in kernel globals.
>>
>>
>>
>> Anyone has an idea on where I have to look.
>>
>>
>>
>> Regards
>>
>
>



Re: Problem in debug mode CE6 by fd

fd
Wed Feb 06 10:12:25 PST 2008

Did something just for pinpoint where the might occurs.

I have replace:
kern.dll, kern.map, kern.pdb, kern.rel
from my RETAIL folder to DEBUG folder and do a Make run-time image.

Now my system starts and connects normally with the debugger.

One thing i did not mention, is that I have applied all Qfes available.

Is anybody knows if there are problems with some Qfes?

Regards

"fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
news:%23HfrMONaIHA.536@TK2MSFTNGP06.phx.gbl...
> Thank you for this precision
>
> My DEBUG image size is 24 mb. (11 MB in RETAIL).
>
> I have no problem at all in RETAIL even large image (24 mb or more in
> RETAIL).
> With more DEBUG trace enabled (0xffff mask), my system died somwhere in
> KernelInit() / InitMemoryPool() / OEMCacheRangeFlush()!!!
>
> Regards.
>
> "Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
> news:%23$oqbvMaIHA.1960@TK2MSFTNGP02.phx.gbl...
>> CurMSec is intentionally set to that value in debug. It provides a
>> mechanism to test your tick implementation when that variable is about to
>> roll over. Remember that it will eventually reach that value in retail
>> mode too, so your tick implementation must be able to handle it.
>>
>> In this case, that's not likely your problem. You're not getting nearly
>> far enough to even have the tick timer running. More likely, you've got
>> a problem with your memory map in debug mode. One possibility is that
>> your image is too big (debug images are far larger than retail). If that
>> happened you could have an image that wasn't complete and could fail.
>>
>> --
>> Dean Ramsier - eMVP
>> BSQUARE Corporation
>>
>>
>> "fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
>> news:ejnEomMaIHA.600@TK2MSFTNGP02.phx.gbl...
>>> Windows Embedded CE6
>>>
>>> System iMx31 128 mb RAM (custom platform)
>>>
>>> Ethernet BOOT
>>>
>>>
>>>
>>> Image has a standard Shell and use ObjectStore.
>>>
>>>
>>>
>>> Kitl enabled on Ethernet
>>>
>>>
>>>
>>> When I try a retail image (also kitl enabled on Ethernet), it works
>>> perfectly but the same image in debug mode stop after:
>>>
>>> "Windows CE KernelInit".
>>>
>>>
>>>
>>> I check inside OALTimerIntrHandler function and strangly, CurMSec is
>>> initialize with a large value: 0xFFFCF2C0 (in RETAIL this value is 0).
>>>
>>> Because of this:
>>>
>>> // partial code.
>>>
>>> // Reschedule?
>>>
>>> if ((int)(CurMSec - dwReschedTime) >= 0) sysIntr = SYSINTR_RESCHED;
>>>
>>>
>>>
>>> sysIntr is nerver set to SYSINTR_RESCHED.
>>>
>>>
>>>
>>> I try to initialize CurMSec earlier in OemInit and after this sysIntr is
>>> set to SYSINTR_RESCHED.
>>>
>>> But the system Hangs anyway.
>>>
>>>
>>>
>>> It's like there some corruption in kernel globals.
>>>
>>>
>>>
>>> Anyone has an idea on where I have to look.
>>>
>>>
>>>
>>> Regards
>>>
>>
>>
>
>



Re: Problem in debug mode CE6 by Dean

Dean
Wed Feb 06 10:35:36 PST 2008

If you're getting this far, it's either cache, interrupts or memory map.
It's never anything else. Do you have a stuck interrupt someplace, or a
problem with your cache routines?

--
Dean Ramsier - eMVP
BSQUARE Corporation


"fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
news:uXQDpvOaIHA.5768@TK2MSFTNGP03.phx.gbl...
> Did something just for pinpoint where the might occurs.
>
> I have replace:
> kern.dll, kern.map, kern.pdb, kern.rel
> from my RETAIL folder to DEBUG folder and do a Make run-time image.
>
> Now my system starts and connects normally with the debugger.
>
> One thing i did not mention, is that I have applied all Qfes available.
>
> Is anybody knows if there are problems with some Qfes?
>
> Regards
>
> "fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
> news:%23HfrMONaIHA.536@TK2MSFTNGP06.phx.gbl...
>> Thank you for this precision
>>
>> My DEBUG image size is 24 mb. (11 MB in RETAIL).
>>
>> I have no problem at all in RETAIL even large image (24 mb or more in
>> RETAIL).
>> With more DEBUG trace enabled (0xffff mask), my system died somwhere in
>> KernelInit() / InitMemoryPool() / OEMCacheRangeFlush()!!!
>>
>> Regards.
>>
>> "Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
>> news:%23$oqbvMaIHA.1960@TK2MSFTNGP02.phx.gbl...
>>> CurMSec is intentionally set to that value in debug. It provides a
>>> mechanism to test your tick implementation when that variable is about
>>> to roll over. Remember that it will eventually reach that value in
>>> retail mode too, so your tick implementation must be able to handle it.
>>>
>>> In this case, that's not likely your problem. You're not getting nearly
>>> far enough to even have the tick timer running. More likely, you've got
>>> a problem with your memory map in debug mode. One possibility is that
>>> your image is too big (debug images are far larger than retail). If
>>> that happened you could have an image that wasn't complete and could
>>> fail.
>>>
>>> --
>>> Dean Ramsier - eMVP
>>> BSQUARE Corporation
>>>
>>>
>>> "fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
>>> news:ejnEomMaIHA.600@TK2MSFTNGP02.phx.gbl...
>>>> Windows Embedded CE6
>>>>
>>>> System iMx31 128 mb RAM (custom platform)
>>>>
>>>> Ethernet BOOT
>>>>
>>>>
>>>>
>>>> Image has a standard Shell and use ObjectStore.
>>>>
>>>>
>>>>
>>>> Kitl enabled on Ethernet
>>>>
>>>>
>>>>
>>>> When I try a retail image (also kitl enabled on Ethernet), it works
>>>> perfectly but the same image in debug mode stop after:
>>>>
>>>> "Windows CE KernelInit".
>>>>
>>>>
>>>>
>>>> I check inside OALTimerIntrHandler function and strangly, CurMSec is
>>>> initialize with a large value: 0xFFFCF2C0 (in RETAIL this value is 0).
>>>>
>>>> Because of this:
>>>>
>>>> // partial code.
>>>>
>>>> // Reschedule?
>>>>
>>>> if ((int)(CurMSec - dwReschedTime) >= 0) sysIntr = SYSINTR_RESCHED;
>>>>
>>>>
>>>>
>>>> sysIntr is nerver set to SYSINTR_RESCHED.
>>>>
>>>>
>>>>
>>>> I try to initialize CurMSec earlier in OemInit and after this sysIntr
>>>> is set to SYSINTR_RESCHED.
>>>>
>>>> But the system Hangs anyway.
>>>>
>>>>
>>>>
>>>> It's like there some corruption in kernel globals.
>>>>
>>>>
>>>>
>>>> Anyone has an idea on where I have to look.
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>
>>>
>>
>>
>
>



Re: Problem in debug mode CE6 by fd

fd
Wed Feb 06 10:44:03 PST 2008

I don't have any OAL... functions that have some debug code.
My system works in RETAIL but not in DEBUG.

kern.dll is not a BSP component it is built from NKmain.lib I think.
oal.exe is the BSP kernel component.

I have replaced kern.dll not oal.exe.

Regards

"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:%23d2J36OaIHA.1184@TK2MSFTNGP04.phx.gbl...
> If you're getting this far, it's either cache, interrupts or memory map.
> It's never anything else. Do you have a stuck interrupt someplace, or a
> problem with your cache routines?
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
> "fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
> news:uXQDpvOaIHA.5768@TK2MSFTNGP03.phx.gbl...
>> Did something just for pinpoint where the might occurs.
>>
>> I have replace:
>> kern.dll, kern.map, kern.pdb, kern.rel
>> from my RETAIL folder to DEBUG folder and do a Make run-time image.
>>
>> Now my system starts and connects normally with the debugger.
>>
>> One thing i did not mention, is that I have applied all Qfes available.
>>
>> Is anybody knows if there are problems with some Qfes?
>>
>> Regards
>>
>> "fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
>> news:%23HfrMONaIHA.536@TK2MSFTNGP06.phx.gbl...
>>> Thank you for this precision
>>>
>>> My DEBUG image size is 24 mb. (11 MB in RETAIL).
>>>
>>> I have no problem at all in RETAIL even large image (24 mb or more in
>>> RETAIL).
>>> With more DEBUG trace enabled (0xffff mask), my system died somwhere in
>>> KernelInit() / InitMemoryPool() / OEMCacheRangeFlush()!!!
>>>
>>> Regards.
>>>
>>> "Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
>>> news:%23$oqbvMaIHA.1960@TK2MSFTNGP02.phx.gbl...
>>>> CurMSec is intentionally set to that value in debug. It provides a
>>>> mechanism to test your tick implementation when that variable is about
>>>> to roll over. Remember that it will eventually reach that value in
>>>> retail mode too, so your tick implementation must be able to handle it.
>>>>
>>>> In this case, that's not likely your problem. You're not getting
>>>> nearly far enough to even have the tick timer running. More likely,
>>>> you've got a problem with your memory map in debug mode. One
>>>> possibility is that your image is too big (debug images are far larger
>>>> than retail). If that happened you could have an image that wasn't
>>>> complete and could fail.
>>>>
>>>> --
>>>> Dean Ramsier - eMVP
>>>> BSQUARE Corporation
>>>>
>>>>
>>>> "fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
>>>> news:ejnEomMaIHA.600@TK2MSFTNGP02.phx.gbl...
>>>>> Windows Embedded CE6
>>>>>
>>>>> System iMx31 128 mb RAM (custom platform)
>>>>>
>>>>> Ethernet BOOT
>>>>>
>>>>>
>>>>>
>>>>> Image has a standard Shell and use ObjectStore.
>>>>>
>>>>>
>>>>>
>>>>> Kitl enabled on Ethernet
>>>>>
>>>>>
>>>>>
>>>>> When I try a retail image (also kitl enabled on Ethernet), it works
>>>>> perfectly but the same image in debug mode stop after:
>>>>>
>>>>> "Windows CE KernelInit".
>>>>>
>>>>>
>>>>>
>>>>> I check inside OALTimerIntrHandler function and strangly, CurMSec is
>>>>> initialize with a large value: 0xFFFCF2C0 (in RETAIL this value is 0).
>>>>>
>>>>> Because of this:
>>>>>
>>>>> // partial code.
>>>>>
>>>>> // Reschedule?
>>>>>
>>>>> if ((int)(CurMSec - dwReschedTime) >= 0) sysIntr = SYSINTR_RESCHED;
>>>>>
>>>>>
>>>>>
>>>>> sysIntr is nerver set to SYSINTR_RESCHED.
>>>>>
>>>>>
>>>>>
>>>>> I try to initialize CurMSec earlier in OemInit and after this sysIntr
>>>>> is set to SYSINTR_RESCHED.
>>>>>
>>>>> But the system Hangs anyway.
>>>>>
>>>>>
>>>>>
>>>>> It's like there some corruption in kernel globals.
>>>>>
>>>>>
>>>>>
>>>>> Anyone has an idea on where I have to look.
>>>>>
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>



Re: Problem in debug mode CE6 by Dean

Dean
Thu Feb 07 06:30:03 PST 2008

I understand that. But the kernel will behave differently in debug versus
retail mode due to optimizations, etc. Usually when you just get to
KernelInit(), then your problem is a low level issue like what I described.
Just because it works in one flavor doesn't necessarily mean that everything
is correct.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
news:%23xcQUBPaIHA.4140@TK2MSFTNGP04.phx.gbl...
>I don't have any OAL... functions that have some debug code.
> My system works in RETAIL but not in DEBUG.
>
> kern.dll is not a BSP component it is built from NKmain.lib I think.
> oal.exe is the BSP kernel component.
>
> I have replaced kern.dll not oal.exe.
>
> Regards
>
> "Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
> news:%23d2J36OaIHA.1184@TK2MSFTNGP04.phx.gbl...
>> If you're getting this far, it's either cache, interrupts or memory map.
>> It's never anything else. Do you have a stuck interrupt someplace, or a
>> problem with your cache routines?
>>
>> --
>> Dean Ramsier - eMVP
>> BSQUARE Corporation
>>
>>
>> "fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
>> news:uXQDpvOaIHA.5768@TK2MSFTNGP03.phx.gbl...
>>> Did something just for pinpoint where the might occurs.
>>>
>>> I have replace:
>>> kern.dll, kern.map, kern.pdb, kern.rel
>>> from my RETAIL folder to DEBUG folder and do a Make run-time image.
>>>
>>> Now my system starts and connects normally with the debugger.
>>>
>>> One thing i did not mention, is that I have applied all Qfes available.
>>>
>>> Is anybody knows if there are problems with some Qfes?
>>>
>>> Regards
>>>
>>> "fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
>>> news:%23HfrMONaIHA.536@TK2MSFTNGP06.phx.gbl...
>>>> Thank you for this precision
>>>>
>>>> My DEBUG image size is 24 mb. (11 MB in RETAIL).
>>>>
>>>> I have no problem at all in RETAIL even large image (24 mb or more in
>>>> RETAIL).
>>>> With more DEBUG trace enabled (0xffff mask), my system died somwhere in
>>>> KernelInit() / InitMemoryPool() / OEMCacheRangeFlush()!!!
>>>>
>>>> Regards.
>>>>
>>>> "Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
>>>> news:%23$oqbvMaIHA.1960@TK2MSFTNGP02.phx.gbl...
>>>>> CurMSec is intentionally set to that value in debug. It provides a
>>>>> mechanism to test your tick implementation when that variable is about
>>>>> to roll over. Remember that it will eventually reach that value in
>>>>> retail mode too, so your tick implementation must be able to handle
>>>>> it.
>>>>>
>>>>> In this case, that's not likely your problem. You're not getting
>>>>> nearly far enough to even have the tick timer running. More likely,
>>>>> you've got a problem with your memory map in debug mode. One
>>>>> possibility is that your image is too big (debug images are far larger
>>>>> than retail). If that happened you could have an image that wasn't
>>>>> complete and could fail.
>>>>>
>>>>> --
>>>>> Dean Ramsier - eMVP
>>>>> BSQUARE Corporation
>>>>>
>>>>>
>>>>> "fd" <remove-f.duchesneau@remove-explora-tech.com> wrote in message
>>>>> news:ejnEomMaIHA.600@TK2MSFTNGP02.phx.gbl...
>>>>>> Windows Embedded CE6
>>>>>>
>>>>>> System iMx31 128 mb RAM (custom platform)
>>>>>>
>>>>>> Ethernet BOOT
>>>>>>
>>>>>>
>>>>>>
>>>>>> Image has a standard Shell and use ObjectStore.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kitl enabled on Ethernet
>>>>>>
>>>>>>
>>>>>>
>>>>>> When I try a retail image (also kitl enabled on Ethernet), it works
>>>>>> perfectly but the same image in debug mode stop after:
>>>>>>
>>>>>> "Windows CE KernelInit".
>>>>>>
>>>>>>
>>>>>>
>>>>>> I check inside OALTimerIntrHandler function and strangly, CurMSec is
>>>>>> initialize with a large value: 0xFFFCF2C0 (in RETAIL this value is
>>>>>> 0).
>>>>>>
>>>>>> Because of this:
>>>>>>
>>>>>> // partial code.
>>>>>>
>>>>>> // Reschedule?
>>>>>>
>>>>>> if ((int)(CurMSec - dwReschedTime) >= 0) sysIntr = SYSINTR_RESCHED;
>>>>>>
>>>>>>
>>>>>>
>>>>>> sysIntr is nerver set to SYSINTR_RESCHED.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I try to initialize CurMSec earlier in OemInit and after this sysIntr
>>>>>> is set to SYSINTR_RESCHED.
>>>>>>
>>>>>> But the system Hangs anyway.
>>>>>>
>>>>>>
>>>>>>
>>>>>> It's like there some corruption in kernel globals.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Anyone has an idea on where I have to look.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>