WinCE

http://blogs.msdn.com/ce_base/archive/2006/10/30/What-is-Virtual-Memory.aspx

Yesterday was the last day for my team mate Ankit in Accord.

He is all set to start off a new career and may be even in a new path in his new company - MindTree. All the best for you Ankit

Hi guys,

Here is a code for changing the current usb client function from Serial to Mass storage dynamically.

/*
* #FUNCTION
*
* @Function: GetUfnController
* @Return: INVALID_HANDLE_VALUE - USB Function device was not found
*   Otherwise, if found
* @Parameters: 
* @Description:
*  Function to get the handle of a USB Client device.
*/
HANDLE GetUfnController()
{
HANDLE hUfn = NULL;
// Get a handle to the bus driver
DEVMGR_DEVICE_INFORMATION di;
memset(&di, 0, sizeof(di));
di.dwSize = sizeof(di);

#ifdef _SEARCH_WITH_GUID_
BYTE rgbGuidBuffer[sizeof(GUID) + 4]; // +4 because scanf writes longs
memset(&rgbGuidBuffer[0],0,sizeof(GUID) + 4);
LPGUID pguidBus = (LPGUID) rgbGuidBuffer;
LPCTSTR pszBusGuid = _T("E2BDC372-598F-4619-BC50-54B3F7848D35");
// Parse the GUID
if (FALSE == ConvertStringToGuid(&pszBusGuid[0],pguidBus) )
return INVALID_HANDLE_VALUE;
HANDLE hf = FindFirstDevice(DeviceSearchByGuid, pguidBus, &di);
#else
HANDLE hf = FindFirstDevice(DeviceSearchByLegacyName, L"UFN1:", &di);
#endif /* _SEARCH_WITH_GUID_ */
if (hf != INVALID_HANDLE_VALUE) {
hUfn = CreateFile(di.szBusName, GENERIC_READ, FILE_SHARE_READ,NULL, OPEN_EXISTING, 0, NULL);
CloseHandle(hf);
}
else {
hUfn = INVALID_HANDLE_VALUE;
}
return hUfn;
} /* GetUfnController */

/*
* #FUNCTION
*
* @Function: ChangeClient
* @Return: TRUE - Client Function change was succesful
*   FALSE - Client Function change failed
* @Parameters:
*   hUfn - Handle to the USB client device
*   pszNewClient - New usb function to be loaded
* @Description:
*  Function to switch the active usb client function driver
*/
BOOL ChangeClient(HANDLE hUfn, LPCTSTR pszNewClient)
{
if(hUfn == INVALID_HANDLE_VALUE || pszNewClient == NULL)
return ERROR_INVALID_PARAMETER;
DWORD dwRet = ERROR_SUCCESS;
UFN_CLIENT_NAME ucn;
_tcscpy(ucn.szName, pszNewClient);
BOOL fSuccess = DeviceIoControl(hUfn,
IOCTL_UFN_CHANGE_CURRENT_CLIENT, &ucn, sizeof(ucn), NULL, 0, NULL, NULL);
return fSuccess;
} /* ChangeClient */

/*
* #FUNCTION
*
* @Function: ConnectionStatus
* @Return: TRUE - Active sync session is active
*          FALSE - Active sync session is not detected
* @Parameters: 
* @Description:
*  Function to Check the connection status of ActiveSync
*/
BOOL ConnectionStatus(VOID)
{
RASCONN   rsconn[10];
DWORD   dwcb, dwConnections;
RASCONNSTATUS rasStatus;
BOOL   bConnected = FALSE;

// Enumerate active connections
dwcb = sizeof(rsconn);
rsconn[0].dwSize = sizeof(RASCONN);
if(RasEnumConnections(rsconn, &dwcb, &dwConnections) == 0) {
if(dwConnections == 0 || rsconn[0].hrasconn == NULL) {
DBG_PRINT ("No current connections\r\n");
}
else{
// Get first RAS connection status
rasStatus.dwSize = sizeof(rasStatus);
if(RasGetConnectStatus(rsconn[0].hrasconn, &rasStatus) != 0) {
 DBG_PRINT ("Could not get RAS connection status\r\n");
}
else{
 // Is it connected?
 if(rasStatus.rasconnstate != RASCS_Connected) {
  DBG_PRINT("Not connected\r\n");
 }
 else {
  if ((0 == wcscmp(L"direct",rasStatus.szDeviceType)) &&
      (0 == wcscmp(L"Serial on USB",rasStatus.szDeviceName))) {
   DBG_PRINT(TEXT("Got an activesync connection..\r\n"));
   bConnected = TRUE;
  }
 }
}
}
}
else {
DBG_PRINT ("Could not enumerate RAS connections\r\n");
}
return bConnected;
} /* ConnectionStatus */

I will explain on how to connect development pc to a board running windows ce 6.0 os image using Activesync. The development board that I used is similar to the Mainstone III development platform (based on a Marvell PXA 270 processor) and activesync is configured to connect over the USB client port.

Previously when I was trying to connect to my development board using activesync from remote tools, i was getting error message that " Unable to load device side components". The samething happens while I was using CETK. But Sctivesync was connceting properly. Then I started digging into discussion forums for finding a solution to this problem. Here is what I found:

1. Open C:\Program Files\Common Files\Microsoft Shared\Windows CE Tools\Platman\target\wce600.
2. Create a folder armV4 and copy the contents of armV4i into this one.
3. Now Open Kernel Tracker or any remote tools.
4. Then follow the same steps specified by Sue in her blog post.

In this post, I will explain about how I debugged a problem in which our development board was taking a lot of time to completly boot up into Windows CE.

Using Celog

In one of my earlier posts, I have mentioned about a cab file that I created with all the celog settings and files. I installed this file on to the development board and configured the registry to launch 'CeLogFlush.exe' during bootup. Also Celog was configured to dump the data into a local file.

[HKEY_LOCAL_MACHINE\init]

"Launch05"="CeLogFlush.exe" -- include celog.dll

[HKEY_LOCAL_MACHINE\System\CeLog]

"Transport"="LocalFile"

"FileName"="celog.clg"

"BufferSize"=dword:100000 // 1MB

"ZoneCE"=dword:815263

"FlushTimeout"=dword:1388 // 5 seconds

"FileFlags"=dword:1 // Keep file open

"ThreadPriority"=dword:C8 // Priority increased to 200

After the complete system was up, I killed the CeLogFlush.exe using ITaskMgr (a really good task manager application) and took the Celog.clg from the device. This output file will contain only the thread IDs, we need to fix this up using readlog (http://devwince.blogspot.com/2008/10/fixing-thread-names-in-celog-output.html).

Now we can view this file in Windows CE Remote Kernel tracker.

Image1

According the Celog data, the booting process went normally till the 7th second since celogflush was started and all the drivers till that point was loaded and threads have been started (that means the XXX_Init routine was completed successfully). But after that the next thread start only at the 52 seconds mark, which was the battery monitor thread. And according the driver loading order in registry, the drivers were the power button monitor and battery driver.

Image2

When I analyzed the XXX_Init of battery driver, I found out that there was a t_printf statement in the init routine. According to the MSDN documentation t_printf will dump the data onto a console, which is again a driver and is not started yet. So when I removed the t_printf statements, the booting speed was back to normal.

:)

Here is another really informative article by the Windows CE Base team.:)

http://blogs.msdn.com/ce_base/archive/2007/11/26/How-does-Windows-Embedded-CE-6.0-start_3F00_.aspx

Special thanks to Bruce Eitman

/*
* Function to query the active drivre list using a search string
*/
VOID QueryDriver (const WCHAR* lpcParam)
{
DEVMGR_DEVICE_INFORMATION devmgrInfo;
devmgrInfo.dwSize=sizeof(DEVMGR_DEVICE_INFORMATION);
HANDLE hDevRes = FindFirstDevice (DeviceSearchByDeviceName, lpcParam,
&devmgrInfo);
if (INVALID_HANDLE_VALUE != hDevRes)
{
do
{
DBG_PRINT(_T("%d , %d , %s, %s, %s, %s\n"),
devmgrInfo.hDevice,
devmgrInfo.hParentDevice,
devmgrInfo.szLegacyName,
devmgrInfo.szDeviceKey,
devmgrInfo.szDeviceName,
devmgrInfo.szLegacyName );
}while (FindNextDevice(hDevRes,&devmgrInfo));
FindClose (hDevRes);
}
else
{
DWORD dwErrorCode = GetLastError();
DBG_PRINT(_T("QueryDriver , code: %d\n"),dwErrorCode);
}
return;
}

Here is the link to really informative article in MSDN regarding the boot sequence in bootloader and kernel.

I found a useful post by Bruce Eitman, regarding how to debug some NOT SO FRIENDLY issues like data aborts etc.

http://geekswithblogs.net/BruceEitman/archive/2008/07/08/summary-of-when-things-go-wrong.aspx

For the windows ce project that we were working on had a lot of power states. As it was a PXA based board, with Mainstone III as the reference platform, we had to map these states to that of PXA.

The low power mode mappings were chosen as below:

• POWER_STATE_SUSPEND - Sleep mode of PXA
• POWER_STATE_OFF - Deep Sleep mode PXA

1. Mapping a SYSINTR value to the wakeup
2. Adding the wakeup configuration specific to the processor

In my previous post, I have explained how to add an interrupt when source code is available.

Now I will explain how to handle an interrupt by writing an IST in the driver. For the reason of continuity, I am using the same power button driver and the Wireless Activity Interrupt (as I explain with in post "Adding Interrupt in OAL").

1. Create an even to be associated with the interrupt

HANDLE g_WlanActiveEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
if( !g_WlanActiveEvent)
{
RETAILMSG(1, (TEXT("WlanActivityMonitorStart: Failed to create Intterupt Event\r\n")));
goto CleanUp;
}

WaitForSingleObject(g_WlanActiveEvent, INFINITE);
InterruptMask(g_SysIntr,TRUE);

if (g_WlanEvent)
{
RETAILMSG(1, (TEXT("WlanThread: Intterupt \r\n")));
PulseEvent(g_WlanEvent);
}

Sleep (1000); // Sleep to ignore some activity as this line toggles a lot
InterruptMask(g_SysIntr,FALSE);

courtesy : Mrs. PV & Mappila sir

Here are links to some really good and informational videos, hosted in microsoft channel.
For me, they were really helpful in building up the basic of the windows ce system architecture.

http://channel9.msdn.com/posts/TravisHobrla/Porting-Drivers-to-Windows-CE-60/

http://channel9.msdn.com/posts/Rory/Windows-CE-Windows-XP-Embedded-and-Windows-Mobile-Explained/

http://channel9.msdn.com/posts/Charles/Bor-Ming-Hsieh-and-Sue-Loh-3rd-Generation-Kernel-for-Windows-CE/

http://channel9.msdn.com/posts/Charles/Juggs-Ravalia--Windows-CE-60-Device-Driver-Model/

When we are having the whole BSP source, there will be cases in which we may need to add interrupt in OAL. This can be accommodate a new driver or add a new functionality to the existing one.

For explaining the procedure I am using the Mainstone BSP that is available in windows ce. Lets assume that we want to add an interrupt for Wireless LAN activity. This interrupt line will be a GPIO line which is mapped to GPIO 91 of PXA.

These are the files that need modification:
* bsp_cfg.h (Src\Inc)
* intr.c (OAL)

In 'bsp_cfg.h', you need to define a SYSINTR (if needed) for the new interrupt that you are about to add.

.............
#define SYSINTR_PWRBTN (SYSINTR_FIRMWARE+14) // 30
#define SYSINTR_WLANACTIVE (SYSINTR_FIRMWARE+15) // 31 - The new interrupt
................

...............
OALIntrStaticTranslate (SYSINTR_WLAN,IRQ_GPIOXX_2_GPIO91);
...............

.................
else if (irq == IRQ_GPIOXX_2_GPIO91)
{
EnableGPIO91Irq(); // define this function for enabling falling or rising
//edge detect and clear edge detect
}
.................

.................
else if (irq == IRQ_GPIOXX_2_GPIO91)
{
DisableGPIO91Irq(); // define this function for clearing falling rising
//edge detect so that interrupt wont come
}
.................

............
//~~ Function for disabling gpio91 interrupt
static void EnableGPIO91Irq(void)
{
SETREG32((PULONG)&g_pGPIORegs->GRER2, XLLP_BIT_27);
}

//~~ Function for enabling gpio91 interrupt
static void DisableGPIO91Irq(void)
{
CLRREG32((PULONG)&g_pGPIORegs->GEDR2, XLLP_BIT_27);
CLRREG32((PULONG)&g_pGPIORegs->GRER2, XLLP_BIT_27);
}