WinCE

Extending Boot loader - Pitfalls & Experiences - Part 2

2010-04-18T22:06:00.001-07:00

Ok, so for implementing access to a SD Card from boot loader what all we need to implement? Here goes:

SD Card block read, identification routines
Routines to identify, validate and read the partition information from MBR
Routines to perform the FAT (VFAT) data from card.

If you check out the sources code in U-boot, these functionalities has been divide in to the following modules:

http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=tree;hb=a47a12becf66f02a56da91c161e2edb625e9f20c

pxa_mmc.c (/drivers/mmc/)
part.c (/disk/)
part_dos.c (/disk)
fat.c (fs/fat)
file.c (fs/fat)

If you directly take the relevant headers and these source files and compile it along E-Boot, of course, you will end up in lot of error, mostly related to

data types
use of __attribute__
structure and macros which are present in Linux headers

Once the errors have been resolved (of course, I am going to leave it up to you), I first enabled and invoked the SD CARD detection routines, I was able to detect the SD CARD, but seemed to failing in reading the MBR, on dumping it, I observed that some bits are not the same as the actual data on SDCARD. So I posted the same on to U-boot mailing list.

http://old.nabble.com/-U-Boot--MMC-problem-in-PXA270-hardware-to27206457.html#a27225880

Then I figured out that the GPIO configuration was getting overridden in another place in code. Corrected it and there it was working like a charm.

Now I enabled, the FAT access module, here again I was stumped with another problem, the compilation was happening properly, but the Flash Image (Eboot.Nb0), was not generating properly. I.e., I observed that there was no change in behavior if I flash the image, with new functionality, also the time stamp on the file was not updating for NB0 file after compilation.

If I disable the new code added, the Image generation was happening properly. So there I was stuck again with another strange problem. So I went through the code again. After some pain staking and careful analysis, I noticed on thing, there were some array declarations like the following, through out the code:

__u8 get_vfatname_block[MAX_CLUSTSIZE];

The macro MAX_CLUSTSIZE, was having the value 65536 . So it is creating an array of very huge size.

So why didn't it create a problem in BIN file creation, instead the problem is showing up NB0 file creation? Answer is very simple:

BIN files are something similar to a loader, i.e. they will have a predefined record format, and will a piece of loader code to unpack the same. On the other hand, NB0 or ROM Image files are like how the Program will be present in memory, when it is loaded.

What happened was that, when trying to create spaces for all the arrays that had been declared in code, the NB0 file creation was failing (Although it was not shown as a warning or error while building). The size of Rom Image for boot loader is restricted to 256KBytes in Eboot.bib.

Now to work around this problem, I used the free memory in RAM and changed these arrays to pointers and initialized them to some addresses in RAM. Now, I had the module working , with reading of any content in an SD Card.

Now moving on to USB Client Upgrade implementation, I will explain the things later on in the next post

Extending Boot loader - Pitfalls & Experiences - Part 1

2010-04-18T20:38:00.000-07:00

Sometimes it becomes required to extend the existing boot loader, mostly for implementing functionalities like firmware upgrade over a variety of medium like USB Pen Drive, USB Client or even a Micro SD Card. In most of the cases, the dead lines (of course always it will be like it) will be very close too.

For the current project, which I am working now, I had to implement such an upgrade over USB Client (which would be used in production team) and a Micro SD Card based upgrade(which will be used by the end users) in the Windows CE Boot loader(E-Boot).

Previously I was able to port, DAS U-boot and Embedded Linux on the same hardware. Anyone who had worked on U-boot, will definitely know about the advantages and the amount of features that it exports for working on an embedded system hardware. It had the implementation of SD Card access with FAT file system. Now for getting around with the task of firmware upgrade assigned to me, within the time limit, was to make use of the code present in U-boot for MMC Card read operations.

Now that I had chosen what I had to do, I started the analysis of what needs to be done for porting. These were the major difference that I was able to observe between the two systems - Windows CE Boot loader and U-boot:

Compilers used for building both of them were completely different. E-Boot was using Microsoft's Cross compiler for ARM. While U-Boot was using GNU C Compiler. This itself is one of the major bottlenecks as the constructs used in one compiler might not be available in the other one. For instance, __attribute__ which was used a lot in U-Boot, was specific to GCC.

The source code of U-Boot was tightly coupled with Linux. The headers that were being used, data structure (for maintaining list etc), were taken from Linux source code.

The data types (typedefs mostly), available and used were a lot, for the same unsigned char, there were lot of typedefs like uint8_t, u8. Same goes for other types too.

There were intelligent mechanisms using macros in U-Boot through various header files for almost every platforms that were available today. That made writing new source code virtually easy.

Then again the objective of my task was to, integrate the module from U-Boot on to E-Boot.

So how do I achieve this? Will explain the details in next post

Windows CE 6.0 R3

2009-09-22T21:42:00.001-07:00

Microsoft has announced the release of Windows CE 6.0 R3 in market. The major enhancement is going to be in terms of UI by bringing in native support for Mircosoft Silverlight.

Downloads will be available by 10/2009. So get ready for an upgrade.

I am waiting for the release for giving it a try.

Check the following links for more information
Mircosoft Page

Post about BSquare BSP support for WINCE6.0 R3 in WindowsFordevices.

Social Bookmarking

2009-07-20T21:11:00.000-07:00

Guys,

I am putting together a social bookmarking page @ delicious.com. Here I will keep on posting whatever useful information that I will find on Windows CE in internet. Hope it would be useful for you guys :). Here is the link

http://delicious.com/vaisakhps/windowsce

Porting of a BSP - SDRAM

2009-06-28T00:36:00.001-07:00

While working on BSP of Windows CE, we will come across cases when we have to port an existing BSP to another hardware. This hardware may have only minor changes like certain peripherals and reducing and/or increasing of memory. I will explain what needs to be done for some of the scenarios involving porting in the upcoming post.

In thos post, I will explain how to systematically change the software when the SDRAM in a hardware is changed. For example, the original BSP had a 32-bit SDRAM interface. But the new hardware is having a 16-bit interface instead.

Before jumping on to changing the code (as the hardware guys will always say, "you just change this bit, it will work straight away...", no pun intented, because it was always like that in my experience and ended up doing a lot of rework ), you need to prepare somethings before doing that.

If you are having a ICE (In Circuit Emulator), that would be of great help, as you can test and troubleshoot a lot of key aspects involving this change.

Do some ground work before jumping in:

Familiarize yourself with the datasheet of the processor which you are using (I have been working on PXA27x on sometime, so will explain based on that).
Prepare some assembly level (or C if you are not familair with assembly routines), which you can run on ICE and check the hardware. Especially whether you are able to access the new SDRAM.
Run some preliminary tests on the SDRAM like writing certain portions of and verifying it.
Scrutinize and tune the SDRAM timing values as they play a very important role in system's performance.

Now lets get on to the practical side. In PXA27x processor, for changing the sdram access from 32-bit to 16-bit and vice-versa can be done by clearing and setting the DWID0 and DWID2 bits in MDCNFG register depending on which bank the SDRAM located.

Once you are through with these steps, you are confidently start the modification involved in OS. Till now what I explained, looks good in theory, but needs a lot of analysis and patience.

While putting together the changes required in the Windows CE BSP, these are the aspects that you need to concentrate on :

The memory initialisation for 16-bit interface
The oem address table change (if required to change the SDRAM size)
Memory parameters in the BIB files (especially config_cebase.bib)

In the mainstone platform the switch to 16-bit mode can be done by setting the macro xlli_SDRAM_16BIT. Check the related code in WINCE600\PLATFORM\COMMON\SRC\SOC\PXA27X_MS_V1\XLLP\SOURCE\xlli_lowlev_init.s.

In config_cebase.bib, change the memory size considering the new ranges and change the address mapping in oemaddrtab_cfg.inc.

With these changes, the bootloader and operating system should move into 16-bit SDRAM mode.

Consider any XScale PXA27x BSP based which is based on the Mainstone III platform. Thanks to the Mainstone BSP developers ofcousrse,

Accessing DrvEscape

2009-06-18T20:33:00.000-07:00

In display drivers, DrvEscape is a function to retrieve information from a device that is not available in DDI for example, issuing a DrvEscape to the PXA27X display driver with GETGXINFO parameters will fill in the GAPI data structure.

For accessing the DrvEscape routines, the following code segment can be used:


  {
          HDC hDC = NULL;
          DWORD Status;
          CEDEVICE_POWER_STATE pwrState = D0;
          hDC = CreateDC(NULL, NULL, NULL, NULL);
          if (NULL != hDC)
          {
             pwrState = D0;
             Status= ExtEscape(hDC, IOCTL_POWER_SET,
                                  0, NULL,
                                  sizeof(pwrState), (LPSTR)&pwrState );
              ReleaseDC(NULL,hDC);
          }
      }

This code will open the display driver and will issue a IOCTL_POWER_SET command to make the display ON. In the PXA27X display driver, uses two display buffers, one for the filling in of graphic data, another a blank buffer , which will be used during D2 to D4 modes.

So if the display driver is in D2-D4 mode, this DrvEscape will bring the driver into D0. This will be equivalent of using SetDevicePower, but Microsoft is not recommending the usage of such APIs as it restricts the device self-management.

Notification for Bluetooth stack Initialisation

2009-06-12T22:55:00.000-07:00

For checking whether the bluetooth stack is up and initialised, you can make use of the manual reset event BTH_NAMEDEVENT_STACK_INITED (L"system/events/bluetooth/StackInitialized").

You can get more information on this page.

Experiencing system slow down in ROM based FS?

2009-06-11T21:15:00.001-07:00

If you are experiencing system performance issues in ROM based File systems, here is a nice tweak to boost up the performance. Most of the times, this slowdown will be due to constant registry flushing in to ROM in background.

[HKEY_LOCAL_MACHINE\init\BootVars]
"RegistryFlags"=dword:2

If this variable is set to 1, it will enable aggressive flushing of registry on to ROM. Setting it to 2 will disable background flushing and can improve performance of system significantly.

Reference: http://msdn.microsoft.com/en-us/library/aa914382.aspx

Cloning OALIOCTL

2009-06-11T21:10:00.000-07:00

In one of my previous posts, I mentioned about cloning OALIOCTL, was thinking of writing about it. But Bruce have already written about. And it was my reference too. So check it out

Adding a kernel IOCTL

2009-06-11T20:48:00.000-07:00

It is assumed that , the OAL code is cloned to the BSP under development, including the ioctl code. For the purpose of explaining the process, the Mainstone III reference platform will be used.

The BSP specific, ioctl will be located under the directory, MAINSTONEIII\SRC\OAL\OALLIB\ioctl.c.

Now lets assume that we need to implement an ioctl to flag the backing up of system alarm setting during shutdown.

Define a new function in ioctl.c as:

BOOL OALIoCtlHalAlarmSet
               (   UINT32 code, VOID *pInpBuffer,
                   UINT32 inpSize, VOID *pOutBuffer,
                 UINT32 outSize, UINT32 *pOutSize)
{
g_oalIoCtlUserAlarmSet = TRUE;
return(TRUE);
}

Define a macro for the new IOCTL.

#define FILE_DEVICE_CUST_OEM   32806

#define IOCTL_DDK_SET_ALARM_FLAG        \
CTL_CODE(FILE_DEVICE_CUST_OEM, 0x0100, METHOD_BUFFERED, FILE_ANY_ACCESS)

Modify g_oalIoCtlTable variable in ioctl.c to add the new ioctl mapping:

const OAL_IOCTL_HANDLER g_oalIoCtlTable[] = {
.....
{
IOCTL_DDK_SET_ALARM_FLAG,
0,
OALIoCtlHalAlarmSet
},
#include 
.....
}

Now we have a kernel ioctl, which can be invoked from any section coming under kernel address space. For making this IOCTL accessible from User space, we need to customise (clone) OALIOCTL, which will be described in another post in detail

USB Client in Sleep mode for PXA

2009-06-11T20:46:00.000-07:00

On resuming from sleep mode of PXA27X, the usb client wont be working straight away. No insertion events will be detected and the device will be shown as an uknown device in PC.

For overcoming this situation, we have to clear the OTGPH bit in PSSR (Power Manager Sleep Status Register). This is a write to clear bit.

OTGPH will be set when entering sleep mode when writing the PWRMODE register and indicates that the OTG pad is retaining state. So after resuming, the USB OTG, UDC and UHC should be configured, then only clear the OTGPH bit.

Referece : Marvell PXA27X Processor Developer Manual, November 3 , 2006

Monitoring events for Network interfaces

2009-06-08T23:37:00.000-07:00

For monitoring events for a network interface, the notification request ioctl IOCTL_NDISUIO_REQUEST_NOTIFICATION in NDISUIO driver can be used.

By using this Notification mechanism, we can capture events for each network interface in Windows CE such as

Bind
Unbind
Power Up
Power down
etc...

A sample implementation is provided in the NDISPWR driver in PUBLIC code
(WINCE600\PUBLIC\COMMON\OAK\DRIVERS\NETSAMP\NDISPWR)

Keeping system alive

2009-06-07T20:00:00.000-07:00

In power manager, the PDD has a certain set of events that it monitors. For eg:

PM_BOOTPHASE2_EVENT
PM_SYSTEM_API_EVENT etc

For more information on events each PDD handles, check the Power manager code available in PUBLIC code (WINCE600\PUBLIC\COMMON\OAK\DRIVERS\PM\PDD).

In those events there is event PM_SYSTEM_TIMEIDLE_RESET (PowerManager/SystemIdleTimerReset), which can used to reset the system activity timer. Check out the following piece of code for doing so.


  HANDLE hSysTmrReset = CreateEvent(NULL, FALSE, FALSE, _T("PowerManager/SystemIdleTimerReset"));
  BOOL bExit = FALSE;
  if (INVALID_HANDLE_VALUE != hSysTmrReset )
  {
      while (FALSE == bExit)
      {
          ResetEvent(hSysTmrReset);
          Sleep(1000);
          SetEvent(hSysTmrReset);
       
          RETAILMSG(TRUE, (TEXT("Reset\r\n")));
          Sleep(20000);
      }
      CloseHandle (hSysTmrReset );
  }
  return 0;

This system, code will keep the system alive by resetting the timer every 20 seconds. I have tested this code and seems to be working. But needs to analyze the system performance on doing so.

Enabling agressive scanning for Wifi

2009-06-03T21:56:00.000-07:00

To enable aggressive scanning for wifi network (preferred or non-preferred ones) in Wireless Zero Configuration in Windows CE, use this registry setting:

[HKEY_LOCAL_MACHINE\Comm\WiFi]
ScanInterval: dword:5

This will set WZC to scan for network every 5 seconds. By default, it is set to 60 seconds. Try tuning this value as per your requirement.

Creating Cab Files

2009-04-23T23:40:00.000-07:00

I found a really cool utility for creating CAB files for a windows ce device - Quick Cab.
Check it out.

http://forum.xda-developers.com/showthread.php?t=400221

War of the worlds

2009-04-15T19:10:00.000-07:00

Guys check out the heated arguement in this post :)

http://blogs.msdn.com/mikehall/archive/2005/01/13/352470.aspx

Keyboard Hooking in Windows CE 6.0

2009-04-08T00:03:00.000-07:00

If you want to monitor system wide keyboard events from an application, then we need to use keyboard hooking using the SetWindowsHookEx & UnhookWindowsHookEx functions. Since we need a system wide hook, we need to place the callback functions in a DLL.




typedef struct {
 DWORD vkCode;
 DWORD scanCode;
 DWORD flags;
 DWORD time;
 ULONG_PTR dwExtraInfo;
} KBDLLHOOKSTRUCT, *PKBDLLHOOKSTRUCT;
.....

VOID InitHook ()
{
 .....
 SetWindowsHookEx(WH_KEYBOARD_LL,hookproc,hinstance,NULL);
 .....
}
....
HOOKDLL_API LRESULT CALLBACK hookproc(int ncode,WPARAM wparam,LPARAM lparam)
{
UINT uMsg = 0;
if(ncode>=0)
{
   if((lparam & 0x80000000) == 0x00000000)//Check whether key was pressed(not released).
   {
      switch((((KBDLLHOOKSTRUCT*)lparam)->vkCode))
      {
         case VK_F1:
            RETAILMSG(1,(TEXT("TRAPPED, F1\r\n")));
            uMsg = WM_USER+755;
            break;

         case VK_F2:
            RETAILMSG(1,(TEXT("TRAPPED, F2\r\n")));
            uMsg = WM_USER+756;
            break;

         case VK_F3:
            RETAILMSG(1,(TEXT("TRAPPED, F3\r\n")));
            uMsg = WM_USER+757;
            break;

         case VK_F4:
            RETAILMSG(1,(TEXT("TRAPPED, F4\r\n")));
            uMsg = WM_USER+758;
            break;
      }

   }
}
return ( CallNextHookEx(hook,ncode,wparam,lparam) );//pass control to next hook in the hook chain.
}

But in Wince 6.0, these APIs have been removed, but is still present in coredll. Hence, they can be accessed using LoadLibrary and GetProcAddress functions.

N.B: Special Thanks Prathamesh S Kulkarni on his article on keyboard hooking in code project.

Modifying the bluetooth authentication dialog

2009-04-07T23:52:00.000-07:00

Hi :)
First of all sorry guys, for the leave of absence, I have been busy lately.

In one of the tasks assigned for me, I had to bring the system back in to ON mode from idle, when any bluetooth activity happens. Activity in the sense, authentication request or a file transfer start etc.

File transfer or any other requests (except for pin request), can be tackled my monitoring the bluetooth stack events. But an authentication request cannot be obtained using the same. The the authentication ui for bluetooth is located in

WINCE600\PUBLIC\COMMON\OAK\DRIVERS\BLUETOOTH\SAMPLE\BTSVC

Its a service (BTSVC), and can modified directly or cloned By AuthenticationDlgProc and the corresponding dialog in the resource file, we can easily modify the behaviour during a bluetooth authentication request. Or a new application can be provided with the same functionality, do doing so , this service must be removed first as only one type of authentication ui will be allowed at a time.

Monitoring for bluetooth events

2009-02-25T00:45:00.000-08:00

Here is a sample code for monitoring incoming connection and authentication requests on a microsoft bluetooth stack:


DWORD BTActivityMonitor ( LPVOID lpParam )
{
MSGQUEUEOPTIONS mqOptions;
memset (&mqOptions, 0, sizeof(mqOptions));

mqOptions.dwFlags = 0;
mqOptions.dwSize = sizeof(mqOptions);
mqOptions.dwMaxMessages = 10;
mqOptions.cbMaxMessage = sizeof(BTEVENT);
mqOptions.bReadAccess = TRUE;

// Create message queue to receive BT events on
HANDLE hMsgQ = CreateMsgQueue(NULL, &mqOptions);
if (! hMsgQ) {
    wprintf(L"Error creating message queue.\r\n");
    goto exit_bt;
}

// Listen for all Bluetooth notifi cations
HANDLE hBTNotif = RequestBluetoothNotifications(
                    BTE_CLASS_CONNECTIONS | BTE_CLASS_DEVICE | BTE_CLASS_PAIRING,
                    hMsgQ);
if (! hBTNotif) {
    wprintf(L"Error in call to RequestBluetoothNotifications.\r\n");
    goto exit_bt;
}

wprintf(L"Waiting for Bluetooth notifications...\r\n");

while (FALSE == bStop) {
    DWORD dwWait = WaitForSingleObject (hMsgQ, INFINITE);
    if (WAIT_OBJECT_0 == dwWait) {
        //
        // We have got a Bluetooth event!
        //

        BTEVENT btEvent;
        DWORD dwFlags = 0;
        DWORD dwBytesRead = 0;

        BOOL fRet = ReadMsgQueue (hMsgQ, &btEvent, sizeof(BTEVENT), &dwBytesRead, 10, &dwFlags);
        if (! fRet) {
            wprintf(L"Error - Failed to read message from queue!\r\n");
            goto exit_bt;
        } else {
            wprintf(L"----------------------------------------\r\n");
            wprintf(L"Got event with id=%d.\r\n", btEvent.dwEventId);
        }
    } else {
        wprintf(L"Error - Unexpected return value from WaitForSingleObject!\r\n");
        goto exit_bt;
    }

}


exit_bt:
// Stop listening for Bluetooth notifications
if (hBTNotif && (! StopBluetoothNotifications(hBTNotif))) {
    wprintf(L"Warning! StopBluetoothNotifications returned FALSE.\r\n");
}

if (hMsgQ) {
    CloseMsgQueue(hMsgQ);
}

return 0;
}

Cloning Public Code

2009-01-06T02:18:00.001-08:00

Here is a nice article by Bruce Eitman for cloning public code

https://geekswithblogs.net/BruceEitman/archive/2008/07/02/platform-builder-clone-public-code.aspx

Article about virtual memory

2008-12-01T19:24:00.000-08:00

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

Buona Fortuna - Good Luck Ankit

2008-11-28T22:05:00.000-08:00

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

Dynamically Changing USB Client Function

2008-11-22T11:18:00.001-08:00

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 */

Enumerating ActiveSync Connections

2008-11-22T11:00:00.000-08:00


/*
* #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 */

Remote Tools and CETK over activesync

2008-11-17T23:53:00.000-08:00

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:

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

Presto!!!... There you have your remote tools working over Activesync.

NOTE: Special Thanks to Sue Loh (Windows CE Base Team Blog) and Yan Sun (CE 6.0 and PlatMan remote tools)

Debugging a booting problem

2008-11-11T21:46:00.000-08:00

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.

The usual bootup time for the development board was around 30-35 seconds, but as we were adding new drivers , the bootup time went up by minutes. The booting was really slow. So I took up this issue.

As i analyzed the booting up process, it was clear that the Boot phase 1 (loading of FMD) was getting over without any hickups. And slow down seems to have been occuring while drivers are getting loaded and initialized.

We can follow two strategies for pin pointing this issue:

Remove each driver one-by-one.
If we are not clear with the source of the problem, then individually eliminating each component one-by-one and observing the behaviour is a straight forward but time consuming way.

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.

Another nice article about booting

2008-11-04T19:43:00.000-08:00

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

Controlling a Stream Interface Driver

2008-10-25T21:50:00.000-07:00

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;
}

--------------------

/*
* Function to load a driver, when provided the driver registry key
*/
VOID LoadDriver (const WCHAR* lpcParam)
{
HANDLE hDriverShell = INVALID_HANDLE_VALUE;
hDriverShell = ActivateDeviceEx( lpcParam,NULL,0,NULL);

if (hDriverShell != INVALID_HANDLE_VALUE && hDriverShell != 0)
{
}
else
{
DWORD dwErrorCode = GetLastError();
DBG_PRINT(TEXT("LoadDriver: Failed to activate driver %d\n"), GetLastError() );
}
return;
}

--------------------

/*
* Function to unload a driver, when provided the diver name
*/
VOID UnloadDriver (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
{
DeactivateDevice(devmgrInfo.hDevice);
}while (FindNextDevice(hDevRes,&devmgrInfo));
FindClose (hDevRes);
}
else
{
DWORD dwErrorCode = GetLastError();
DBG_PRINT(_T("QueryDriver , code: %d\n"),dwErrorCode);
}
return;
}

--------------------

Fixing Thread names in CeLog Output

2008-10-13T04:08:00.001-07:00

When you are debugging on a standalone system (i.e. which is not connected to platform builder, using corecon), you may need to get the celog CLG file and review the performace data for the session in Kernel Tracker.

But the file which you are getting will not have the thread information, it will only have the identifiers for each thread instead of the names. The names of the thread can be acquired using the Readlog utility. First copy the CLG file you obtained from the system into the build release directory and execute the following command :

Readlog -fixthreads celog.clg output.clg

Now output.clg file will have the thread names fixed up.

Fixing Thread Names With Readlog (http://msdn.microsoft.com/en-us/library/aa935935.aspx)

Interrupt ... whats the big deal??

2008-09-29T23:34:00.000-07:00

In most of the discussion forums I have seen that developers are not clear about how interrupts are handled in windows ce. I am familiar with the Xscale and arm architectures. This post will not explain about how to handle or register interrupt in drivers, as it is covered in some of the previous posts. Instead how kernel manages an interrupt in windows ce 6.0. Lets start off with the concept of EXCEPTIONS in arm architectures.

"Exceptions are generated by internal and external sources to cause the processor to handle an event, such as an externally generated interrupt or an attempt to execute an Undefined instruction."
- I took it from the arm reference manual, couldn't put it in any better way myself:)

There are seven types of exceptions supported by ARM:

Reset
Undefined Instruction
Software Interrupt
Prefetch Abort
Data Abort
IRQ
FIQ

When an exception occurs, the processor execution is halted and branches to a predefined address called exception vector. For each exception type, there is predefined exception vector, for example, exception vector for Data abort is 0x00000010 and that of reset is 0x00000000. There is also high vectors in which the exception vectors can be moved to an alternative address range(0xFFFF0000-0xFFFF001C), using bit[13] of the coprocessor 15 register 1 .

In the exception handler the banked version of register such as R14 and SPSR are used to save and restore the processor state.

Starting point for analyzing the exception handling in Windows ce for ARM architectures can be

WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\exvector.s

Defenition to each of this hanlders can be found in armtrap.s (WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM)

This vector table will be loaded into the higher part of physical page at 0xffff0000 (same as the High vector address), along with other kernel data in ARM_HIGH structure (WINCE600\PRIVATE\WINCEOS\COREOS\NK\INC\nkarm.h)

Here are some references that you can start off with

- ARM Architecture Reference Manual

( http://www.arm.com/miscPDFs/14128.pdf)

Understanding the bootup sequence of bootloader and kernel

2008-09-24T02:08:00.000-07:00

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

http://msdn.microsoft.com/en-us/library/aa446905.aspx

Querying that powerstate of an NIC

2008-09-23T20:22:00.000-07:00

This one is a continuation of the last post, Here is a code for chcking the current power state of an NIC

// Returns TRUE if device is enabled otherwise FALSE
BOOL QueryNIC (wchar_t* InterfaceName)
{
TCHAR szName[MAX_PATH];
int nChars;
TCHAR* pszAdapter;
TCHAR multiSz[257];
DWORD cbBuffer = sizeof(multiSz);
CEDEVICE_POWER_STATE Dx = PwrDeviceUnspecified;
BOOL bDevPowered = TRUE;

pszAdapter = new TCHAR[wcslen(InterfaceName)+1];
wcscpy_s(pszAdapter,wcslen(InterfaceName)+1,InterfaceName);
nChars = _sntprintf_s(szName,
   MAX_PATH-1,
   MAX_PATH-1,
   _T("%s\\%s"),
   PMCLASS_NDIS_MINIPORT,
   pszAdapter);
szName[MAX_PATH-1]=0;

if(nChars != (-1))
::GetDevicePower(szName, POWER_NAME, &Dx);

if (!IsValidDx(Dx))
{
bDevPowered = FALSE;
}
if (D4 == Dx)
{
bDevPowered = FALSE;
}
delete pszAdapter;
return bDevPowered ;
}

Controlling an Ethernet Adapter using Power Manager API

2008-09-22T22:36:00.000-07:00

i have to thank one person (seriously I forgot this name... i am really bad a remembering names and numbers), he posted an article in codeproject.com regarding this functionality. Then I found more helpful code in completing the circle.. :)

WINCE600\PUBLIC\COMMON\OAK\DRIVERS\NETSAMP\NDISPWR

This is a sample program given in windows ce 6.0 showing how to query and the set the power state of network interface using deviceIocontrols (specifically, ndis ioctls for binding and unbinding the adapter after a power state change) and setDevicePower functions.

Here is the code for controlling (enabling and disabling, its the same operation as in enabling and disabling a network interface in network connection applet in control panel) an NIC.

Pay attention to the high lighted part of code.

void ControlNIC(wchar_t* InterfaceName,BOOL bEnable)
{
HANDLE hNdisPwr;
NDISPWR_SAVEPOWERSTATE SavePowerState;
TCHAR szName[MAX_PATH];
int nChars;
TCHAR* pszAdapter;
TCHAR multiSz[257];
DWORD cbBuffer = sizeof(multiSz);

hNdisPwr = CreateFile((PTCHAR)NDISPWR_DEVICE_NAME,
   0x00,0x00,NULL,
   OPEN_EXISTING,
   FILE_ATTRIBUTE_NORMAL
   | FILE_FLAG_OVERLAPPED,
   (HANDLE)INVALID_HANDLE_VALUE);

if (hNdisPwr != INVALID_HANDLE_VALUE)
{
SavePowerState.pwcAdapterName = InterfaceName;
if (bEnable)
{
SavePowerState.CePowerState = PwrDeviceUnspecified;
}
else
{
SavePowerState.CePowerState = D4;
}

BOOL ret = DeviceIoControl(hNdisPwr,
   IOCTL_NPW_SAVE_POWER_STATE,
   &SavePowerState,
   sizeof(NDISPWR_SAVEPOWERSTATE),
   NULL,0x00,NULL,NULL);

// TODO: take care of the return value 'ret '

CloseHandle(hNdisPwr);

   // Just composing a Class-Qualified Device Name, to pass on to SetDevicePower
pszAdapter = new TCHAR[wcslen(InterfaceName)+1];
wcscpy_s(pszAdapter,wcslen(InterfaceName)+1,InterfaceName);
nChars = _sntprintf_s(szName,
   MAX_PATH-1,
   MAX_PATH-1,
   _T("%s\\%s"),
   PMCLASS_NDIS_MINIPORT,
   pszAdapter);
szName[MAX_PATH-1]=0;

DWORD res = 0;
if(bEnable)
{
res = SetDevicePower(szName,
   POWER_NAME,
   PwrDeviceUnspecified);
}
else
{
res = SetDevicePower(szName,
   POWER_NAME,
   D4);
}

// TODO: take care of the return value 'res'

StringCchCopy(multiSz, (cbBuffer / sizeof(TCHAR))-1, pszAdapter);
multiSz[::_tcslen(multiSz)+1] = _T('\0'); // Multi sz needs an extra null

BOOL bRes;

if (bEnable)
{
bRes = DoNdisIOControl(IOCTL_NDIS_BIND_ADAPTER,
   multiSz,
   (_tcslen(multiSz)+2) * sizeof(TCHAR),
   NULL,NULL);
}
else
{
bRes = DoNdisIOControl(IOCTL_NDIS_UNBIND_ADAPTER,
   multiSz,
   (_tcslen(multiSz)+2) * sizeof(TCHAR),
   NULL,NULL);
}

// TODO: take care of the return value 'bRes '
}

}

While changing the power state of a device, be sure for bind and unbind an adapter so that NDIS can take care of the protocol drivers.

Adding Low Power modes in PXA - P4

2008-09-17T05:26:00.000-07:00

So far,we have discussed about how to put pxa into low power mode, how to wake it up, and briefly on how operating system restore things to the prior state after a transition to low power mode. Now lets put the bits and pieces together and see how windows ce does the low power mode transition in case of PXA.

As I have mentioned in the previous posts, we need to add the wakeup configuration first and then put the processor in to the low power mode.

For purpoes of explaining the concept, I will how to add a wakeup for GPIO 11 which is connected to the activity line of a communication module.

Adding the wakeup source
1) In OAL interrupt code(intr.c and bsp_cfg.h), add the code for creating a new interrupt corresponding to the wakeup source.

bsp_cfg.h - Add the new sysintr for the wakeup line

....
#define SYSINTR_COMMMOD_WAKEPUP (SYSINTR_FIRMWARE+22)
....

intr.c - map the sysintr to gpio 11 and add code for managing that
BOOL BSPIntrInit()
{
....
OALIntrStaticTranslate (SYSINTR_COMMMOD_WAKEPUP,IRQ_GPIOXX_2_GPIO11);
....
}

2) In OAL power code (power.c), add code for setting the pwer register. In mainstone bsp, the wakeups are register while OS starts (BSPPowerOffInit function)and the pwer value is written only while going into low power mode (BSPPowerOff).

BSPSetWakeSrc function - add a case for gpio 11 and set the gpio11 bit in the pPwer global variable. This variable will be written to the actual PWER register while going into suspend.

......
case IRQ_GPIOXX_2_GPIO11:
pPwer->gpio11 = 1;
OALMSG(1, ( L"BSPSetWakeSrc: IRQ Communication module source\r\n", irq));
break;
......

BSPGetWakeSrc function - add case for gpio 11 here also.This function to return the IRQ value if the PEDR (Power manager edge detect register) bit for gpio 11 is set.

....
else if (pPedr->gpio11)
{
*pSrcIrq = IRQ_GPIOXX_2_GPIO11;
}
....

BSPPowerOffInit function - use the OALIoCtlHalEnableWake function to set the global variable (g_oalWakeMask, an array) with the sysintr value corresponding to gpio11.
UINT32 commSysIntr = SYSINTR_COMMMOD_WAKEPUP;
...

OALIoCtlHalEnableWake(IOCTL_HAL_ENABLE_WAKE, &commSysIntr, sizeof(commSysIntr), NULL, 0, NULL);
...

While the BSPPowerOff function finds out which sysintr is mapped as a wakeup using OALPowerWakeSource and OALIntrTranslateSysIntr functions and sets the pwer bits with BSPSetWakeSrc function call.

When system resumes, BSPGetWakeSrc is used to get the wake cause and is stored in g_oalWakeSource variable which can be retrieved using kernel ioctl IOCTL_HAL_GET_WAKE_SOURCE

Adding Low Power modes in PXA - P3

2008-09-17T05:20:00.000-07:00

Wakeup Sources

When PXA is in low power modes such as Standby, Sleep or DeepSleep, the processor can be brought out using "Wakeups".

Wakeup is an "external or selected internal event". For example, assume that the power button is connected to GPIO0 of the processor, pressing of power button can be a wakeup source to the processor. Not all the GPIOs can act as wakeup for processor. For PXA the GPIO <116,> can act as wakeup sources. Also there are other wakeup sources such as USB host & client, RTC are wakeup sources.

Now we may not need to wakeup the processor for activity from any of these sources. Hence we can select the required wakeup source using the Power Manager Wake-up Enable (PWER) register. Also for GPIO wakeup sources, the edges needs to be configured using the Power Manager Rising Edge Detect Enable (PRER) and Falling Edge Detect Enable (PFER) register, so that wakeup will only happen for the selected edge of the transition on the GPIO.

NOTE: Take special care in configuring the direction of the GPIO which is chosen as a wakeup. If a wakeup source is configured for a GPIO which is configured as output, some undesirable results can happen.

For keypad and usim wakup there are seperate set of registers too for configuring specifics.

So in short, while configuring a gpio wake source in pxa, the following things should be taken into consideration:

PWER, selecting the wakeup source
PFER and PRER, fo which edge of GPIO transition , system needs to wakeup
GPDR, gpio should be configured as input

When things go wrong....

2008-09-16T22:26:00.000-07:00

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

Adding Low Power modes in PXA - P2

2008-09-16T02:10:00.000-07:00

Power Modes in PXA

PXA has the following power modes

Normal mode
Idle mode
Deep idle mode
Standby mode
Sleep mode
Deep Sleep mode

Each mode is characterized by the power domains that will be kept active and the clocks that will be running. For example in Sleep mode all the external low voltage power domains (i.e. domains controlled by PWR_EN pin of PXA) is disabled. While on the other hand, in Deep Sleep mode both the external low voltage and high voltage power domains are disabled as both PWR_EN and SYS_EN pins are de-asserted while entering the low power mode. The choice of which power mode to use for each depends solely on the power consumption requirements of the product.

In the beginning of the project, we mapped the Standby mode of PXA to POWER_STATE_SUSPEND state of Windows CE. But as we had a tight power consumption requirement for the Suspend mode, we had to re map the state to Sleep mode of PXA instead of standby.

Transition of Power Modes

For initiating a power mode transition in PXA, we need write in to the coprocessor 14 , register C7 (PWRMODE). Writing the bit pattern for each pattern corresponding to the power mode in to the PWRMODE[M] bits initiates the transition. For eg:

XllpPmEnterDeepSleep FUNCTION

ldr r3, =0x00000007
mcr p14, 0, r3, c7, c0, 0
nop
.......

A call to this assembly routine will initiate a transition to deep sleep mode.

Context Restoration

While going into low power modes such as Sleep or Deep Sleep, the processor contents can get corrupted.

Lets take the example of Sleep mode. In Sleep mode, the PC (Program Counter) value is corrupted along with some other set of registers. So in order to tackle this situation, operating systems are doing a context storage and restoration while going into low power mode. It stores the status of all the required registers such as GPIO configurations, level, stack address, core configuration registers in to a memory area. The address of this memory area is kept in a register which will be retained during the low power mode. In the case of PXA, it is the Power Manager Scratch Pad Register (PSPR). This register value will be maintained during a sleep reset, but will be cleared during GPIO, power on , hardware or watch dog resets.

So while going in to sleep mode, the required information is stored in a data area in RAM and the address to this area is stored in PSPR register. While resuming from sleep mode, the boot loader will check the PSPR register and will restore the configuration that is stored in the data area.

NOTE: bear in mind that the data area is in RAM, so the RAM needs to be properly initialized after a sleep reset, otherwise the boot loader can hand while trying to access the restoration area.

Adding Low Power modes in PXA - P1

2008-09-15T23:44:00.000-07:00

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

As you may have noticed in the Mainstone BSP's OAL code (the common soc code for pxa, i.e., WINCE600\PLATFORM\COMMON\SRC\SOC\PXA27X_MS_V1\OAL\POWER\off.c), the OemPowerOff Function uses the Deep Sleep mode of PXA. This function will be invoked from kernel when power manager issues a power off system.

Now with the new requirement for our software, we had to modify the existing OAL code and the power manager to add and map the new states to that of the PXA.

In this post I will walk you through on steps involved in adding a wakeup source in OAL.

We can splits the process in to two parts

Mapping a SYSINTR value to the wakeup
Adding the wakeup configuration specific to the processor

The detailed steps, I will explain in next post...

CeLog

2008-09-15T23:01:00.000-07:00

Its one of the most helpful tools that I have used in WinCE BSP development. Celog is an event-tracking tool that logs a set of predefined ( I think configured or filtered would be an apt word) for this) CeLog collects the data given by various sources such as applications or drivers in a location configured in registry.

Using tools such as CeLogFlush.exe, we can periodically collect the data and can be analyzed in a development workstation.

A Special Thanks to Sue Loh, for posting a really helpful and detail documentation in her blog in MSDN for using CeLog along with tools such as kernel tracker.

While working on the wrist pc project, we were experiencing some unexpected slow of system while booting up and running applications and we were pondering in dark just to figure out the cause of the snail's pace performance. Then I came across the tutorial given by Sue Loh in her microsoft blog on using CeLog on a standalone machine.

Previously I had used Remote Kernel Tracker, which is built into the platform builder for connecting to a development board using CoreCon and use CeLog to gather Kernel Data (such as interrupt, thread switching, events and other information), on a real time basis (well pretty close to real time). But for this the board needs to be connected to over ethernet or serial to a development work station.

Most of the times problems will arise while testing under real scenarios. So debugging such issues, I came up with a solution. I made a CAB file with the following things:

celog.dll
celogflush.exe
ITaskMgr_arm.exe (A free task manager I found in net, http://urana.info/mobile/wince/itaskmgr/index.html)
oscapture.exe

(Also added shortcuts in start menu to launch the exes too, just for the ease of use)

I distributed this cab file among my team and asked them to install in all the boards that we were using. So at any point of the system is showing any slowness, start the 'CeLogFlush.exe' application, which will periodically dump the performance data on to a file. After significant data is gathered, they can use the ITaskMgr_arm.exe to kill the CeLogFlush flush instance and then take the dumped file.

This file can be opened in Kernel tracker to view the information.

In later posts I will explain in detail about CeLogFlush and other tools for performance monitoring.

Regarding how to analyze the performance data, Sue has put up a detailed tutorial in her blog.

Writing IST for an interrupt defined in OAL

2008-09-08T12:03:00.000-07:00

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;
}

2. Associate the Interrupt with the event using SYSINTR value

UINT32 g_SysIntr = SYSINTR_WLAN;
......
result = InterruptInitialize(g_SysIntr, g_WlanActiveEvent, NULL, 0);
if(!result)
{
RETAILMSG(1, (TEXT("WlanActivityMonitorStart: InterruptInitialize() failed. GetLastError=0x%x\r
\n"),GetLastError()));
goto CleanUp;
}

3. Start a thread for handling the interrupt.

g_WlanThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) WlanThread, NULL, 0, NULL);
if ( g_WlanThread == NULL )
{
RETAILMSG(1, (TEXT("WlanActivityMonitorStart: Failed to create WlanActive
Intterupt Thread\r\n")));
goto CleanUp;
}

4. In the thread, wait for the event to happen using the WaitForSingleObject or WaitForMultipleObjects API.

INT WlanThread (VOID)
{
while(!g_FlagExitThrd)
{
WaitForSingleObject(g_WlanActiveEvent, INFINITE);
.............
}
return ERROR_SUCCESS;
}

5. Perform the necessary operations to service that interrupt. Here I am pulsing another event to notify some other sets of appication.

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);

6. Signal the completion of interrupt handling using InterruptDone

InterruptDone(g_SysIntr);

Dreams or Nightmares of an embedded systems engineer

2008-09-08T07:45:00.000-07:00

courtesy : Mrs. PV & Mappila sir

Common Mistakes made - P2

2008-09-08T03:16:00.001-07:00

While going into low power modes of windows while coming back up, restore the processor and peripherals back to the state it was before.

One problem that we had faced in our project was regarding the restoration of PCCARD timings. Although we were using the original MainstoneIII BSP in Wince6, we had to modify the boot loader and other startup initializations to match the new board which we were designing. On doing so, we commented out the PCCARD timing initializations in xlli_low_level_init.s file.

On PCCARD socket, we had a Wireless LAN card, which was working properly. But after a suspend-resume cycle, the network adapter was shown as down in the drivers. We couldn't figure out what was the reason for this behaviour. Wasted a lot of precious time in debugging the issue. Using a debug version of the driver from vendor, we were able to figure out that after a suspend-resume cycle, the driver was not able to access the card.

So we decided to try a reinitialization of the full PCCARD driver. On trying the pccard and wlan was back up in working state. But the entire driver initialization was slowing down the resuming of the system.

We again analyzed the reinitialization process, then it hit me. I decided to access the pccard attribute memory immediatly after the resuming in OAL. There I came to realize that the problem is way before the OS.

We did a walk though of the Boot loader code, i.e. the path followed during a sleep reset and found out that the section of code for re-initialization of pccard was commented.

Although we fixed the problem, we had to waste a lot of precious project development time in debugging the issue.

So when dealing with low level initializations in bootloader or restoration code, be careful what you are modifying. One way or the other that will come back to haunt you :)

Some useful videos from Microsoft Channel9

2008-09-07T11:39:00.000-07:00

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/

Adding Interrupt in OAL

2008-09-07T11:21:00.000-07:00

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
................

Now in OAL, intr.c, make the following changes:
1. In BSPIntrInit() function, add a call to OALIntrStaticTranslate() to map the
the new SYSINTR v alue to the GPIO.

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

2. In BSPIntrEnableIrq(), add the case of enabling the GPIO Interrupt

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

3. In BSPIntrDisableIrq(), add the case of enabling the GPIO Interrupt

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

4. Define the functions for enabling and disabling the gpio interrupt

............
//~~ 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);
}

This is how we add a new interrupt in OAL.

My friend mukesh has written in his blog, how to dynamically add an interrupt handler, when OAL source code is not available.

In the next posts, I will explain how to add an IST (Interrupt Service Thread) to take care of this interrupt.

Making a device "Power-Managed"

2008-09-07T11:02:00.000-07:00

Power manager uses IOCTLs to interact with Power-Managed devices. So inorder to make a device power managed implement certain set of IOCTLs in the driver with registry changes.

For the purpose of explaining, i am taking the sample of the Power Button driver implemented in Mainstone platform available in windows ce 6.0. Please bear in mind that this driver is already having a function which monitors system power state transitions using Notification Queues. But I am not going to make use of them.

Here I will briefly describe the steps involved in doing the same. We can divide the changes in to two parts:

Change in registry settings for driver
Implementing IOCTLs

Change in registry settings for driver

Now as the documentation for power manager, each power managed device needs to be classified under a certain category i.e Generic power-manageable devices, Power-manageable block devices and Power-manageable NDIS miniports. Each class is identified by a certain GUID(defined in pm.h). Associating a device to a power manager class is really easy, just by adding a registry entry to the device driver entry, as follows.

I will make this power button driver as a generic device

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\PWB]
"Prefix"="PWB"
"Dll"="mainstoneii_pwrbutton.dll"
"Order"=dword:3
"IClass"="{A32942B7-920C-486b-B0E6-92A702A99B35}" ;; we are making it as generic device over here

When device manager loads the driver, it will associate the device to the class.

Now power manager will start issuing the IOCTLs to the driver and query the capabilities of the driver. The details I will explain in the next section.

Note : We should atleast implement IOCTL_POWER_CAPABILITIES in a driver to make it power managed

Implementing IOCTLs

The driver needs to implement the following IOCTLs for interacting with power manager:

IOCTL_POWER_CAPABILITIES **
IOCTL_POWER_GET
IOCTL_POWER_QUERY *
IOCTL_POWER_SET
IOCTL_REGISTER_POWER_RELATIONSHIP *

** - This IOCTL is mandatory for the entire thing to work
* - rather optional

When power manager receives a request to register a device driver under a particular device class, it first passes IOCTL_POWER_CAPABILITIES to the driver. If the call returns false, the driver wont be registered otherwise it will be. This IOCTL should return the device capabilities.

BOOL IOControl( ............. )
{
................
case IOCTL_POWER_CAPABILITIES :
if (NULL != pOutBuf)
{
memcpy(pOutBuf, &PWBDrvPowerCaps, sizeof(PWBDrvPowerCaps));
*pdwBytesTransferred = sizeof(PWBDrvPowerCaps);
OutBufLen = sizeof(PWBDrvPowerCaps);
dwErr = ERROR_SUCCESS;
}
else
{
dwErr = ERROR_INVALID_PARAMETER;
}
break; // IOCTL_POWER_CAPABILITIES
...............
if(dwErr != ERROR_SUCCESS) {
bRc = FALSE;
} else {
bRc = TRUE;
}

return bRc;
}

The variable PWBDrvPowerCaps contains the device power capabilities of the driver in a POWER_CAPABILITIES structure.

POWER_CAPABILITIES PWBDrvPowerCaps =
{
DX_MASK(D0) | DX_MASK(D2) | DX_MASK(D3) | DX_MASK(D4),
0,
0,
{
0x00000000, // D0
0x00000000, // D1
0x00000000, // D2
0x00000000, // D3
0x00000000 // D4
},
{
0x00000000, // D0
0x00000000, // D1
0x00000000, // D2
0x00000000, // D3
0x00000000 // D4
},
0
};

For information on the meaning of each parameter please refer MSDN. After returning true from the IOCTL, power manager will register this device under the requested class in registry.

From now on wards, when ever a state change occurs (or is requested) for the device or system, power manager will send the IOCTL_POWER_SET to the driver and the driver can take care of the same.

case IOCTL_POWER_SET:
if ( pOutBuf != NULL )
{
SetPwbPowerState(*(PCEDEVICE_POWER_STATE) pOutBuf);
dwErr = ERROR_SUCCESS;
}
else
dwErr = ERROR_INVALID_PARAMETER;
break; // IOCTL_POWER_SET

In SetPwbPowerState(), you can define the power depending on the paramater.

My team

2008-09-07T09:39:00.000-07:00

my teammates..
muku, ambi n ankit

@ taj gateway with gopu, cimbu, shobin, ambi, me, muku n ankit

The whole team :)

work'n'fun

Common Mistakes made - P1

2008-09-07T07:56:00.001-07:00

This is one the common mistakes that I have made while I was working on windows ce and also saw others making them too....

"Don't Forget the BIB file"

When adding extra drivers or other applications in the BSP, we always missed out adding the entry in BIB file. During development from platform builder, we wont notice any problem (if we don't pay attention to the LOG messages). Because while working from a development platform, there will be an extra directory in "My device" folder, called Release. So when the the file is required to be loaded, application or driver dll, it will be loaded from this directory.

But when the device is in stand alone mode, this Release directory wont be present and the DLL or application will fail to load. Most of the times we were wondering whats happening. We were concentrating only on the registry settings. Didn't notice that the file loading was failing. After some digging around and wasting valuable time, we found out the culprit :)

So think of this point while adding your drivers ok :)

Dont miss the BIBle :)

First Windows CE Project

2008-09-07T07:23:00.000-07:00

My first windows CE project was the wrist pc project. Development of a wrist wearable computer for an Italian client. Our aim was to design a board and the software compliant with the specification given by the client.

The board will have a PXA270 processor from Marvell, with the following peripherals:

1X USB Host port
1X USB Client port
a 640x480 - 18bpp display
Accelerometer
Ambient Light sensor
Keypad
Micro SD card slot
Wireless LAN
Wireless WAN (Phone module)

..... and a lot of other stuff.

In the team first formed, I was not there. Later on Prashanth added me in to the team for BSP and application development to help out Sundhar and Ambika. Later on Ankit, Mukesh, Gopu and Rajesh joined in to our team. I was kind of a one big happy family ... Although with the occassional "nuclear bomb explosions" by Prashanth, for things not going as smoothly as it was supposed to be. :)

First itself, I was exhilerated by the shear size and complexity of the project. Well most part was the excitment. I had no prior experience in Windows CE or in Embedded Systems. The only things that I had ever closer to mircoprocessors or embedded systems was the Microprocessor class which I had in fourth or fifth semester in my college. And also no one in the company had prior experience in working on windows ce. But Ambika and Sundhar had worked on embedded systems projects before, they have been a great help for me in picking up the pieces.

We also had one more team working on the design and development of the hardware. We were concentrating on the software aspects of them.

....
continued in next part