- Platform Builder Basics
- Creating a New Platform with the Platform Wizard
- Building and Executing the Platform
- Creating Applications for Your Platform
- Running Windows CE on a CEPC
- Integrating New Components into the Image
- Customizing the Build Using Environment Variables
- Extending the Platform Builder Catalog
- Creating a New Board Support Package
- Summary
Running Windows CE on a CEPC
Running Windows CE is not as straightforward as creating a new platform and project. This task requires two separate operations. The final build of Windows CE, also referred to as the image, must be uploaded to the target platform first. Next, the kernel debugger built into the Platform Builder IDE must connect with the debug kernel on the target. There are several ways to upload an image and debug it. For starters, we will focus on uploading via the parallel port and debugging over the serial port. These methods are supported on all versions of Windows CE, including those that use the early version of Platform Builder called the Embedded Development Kit (EDK).
How does one upload the image to that target platform? You'll need a bidirectional enhanced parallel port (EPP) on both sides of the equation: the workstation and the platform. It is a good idea to make sure that the parallel port is in EPP mode by checking the settings in the system BIOS. The parallel port cable itself must be tweaked a bit. First you'll need a male DB25 connector at both ends. Next, the cable itself must be wired as shown in Table 3.3. You can order such a cable from a variety of vendors, but it's not difficult to make one yourself. Start with a regular parallel port cable and add an expansion box with the appropriate pins soldered to meet the requirements in Table 3.3. If you don't have an EPP-compatible port on the workstation or the CEPC target, you can buy a plug-in ISA card that supports an EPP-compatible port. The EPP-compatible port is jumper configurable on these cards. Be sure to avoid conflicts with your regular parallel port in the workstation or CEPC.
Table 3.3 CESH Parallel Port Cable Pin Connections
|
Pin |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
|
Pin |
10 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
1 |
14 |
16 |
17 |
11 |
— |
12 |
13 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
The serial connection used to debug the kernel is fortunately quite straightforward, simply requiring a serial cable. Once both connections have been set up, you are ready to upload.
An upload is carried out via the Windows CE Debug Shell Tool (CESH). CESH is capable of uploading images to the target via several transports, including serial and Ethernet. For the exercise we are conducting, we have already decided to use CESH's parallel port capabilities.
To use CESH to upload the image, we must first start a command prompt. Platform Builder provides a convenient way to create a command prompt and change directory to the release directory for the platform under development with a few simple mouse clicks. From the Build menu, select Open Build Release Directory. This selection will launch a command prompt in the release directory of the platform. The release directory of a platform refers to the repository for the final phase, \WINCE212\PUBLIC\ADAM\RELDIR\X86_DEBUG. This directory contains the final Windows CE image to be uploaded to the target. The image is called nk.bin and must be sent to the target in its entirety. This is accomplished by the following command:
Cesh -p CEPC Nk.bin
The -p option of CESH indicates the profile that CESH must use. In this case, the profile is called CEPC. Profiles for CESH are set up in the registry by the Platform Builder installation procedure. The CEPC profile urges CESH to use the parallel port with some predefined settings that configure the parallel port protocol. When using this profile, CESH starts passing nk.bin, chunk by chunk, to the parallel port. The parallel port base address and interrupt level are assumed to be the default values for LPT1 (base address 0x378 and IRQ 7). Should this change on your workstation, you must edit the CEPC profile directly to reflect the changed parallel port settings. To change these settings, you must change the registry values shown in Listing 3.1.
Listing 3.1 CESH registry settings
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ppsh\CEPC: InterruptLevel = REG_DWORD 7 InterruptMode = REG_DWORD 1 InterruptVector = REG_DWORD 7 PortAddress = REG_DWORD 0x378
On a CEPC, at the other end, a tool called Loadcepc communicates with CESH to receive pieces of the operating system image and then loads and boots the operating system. You must start by creating a bootable floppy, preferably with MS-DOS 6.22, and put loadcepc.exe on it. This floppy disk should be used to boot the CEPC. Loadcepc is available in Platform Builder, and its source code is in the CEPC platform directory. Once the two utilities start to communicate, a progress bar indicates the portion of the image that has been transferred successfully between the workstation and the CEPC (Figure 3.11). After the entire image has been uploaded, Windows CE will boot on the CEPC.
){kind=link}
Figure 3.11 Uploading an image using CESH
Kernel Debugging
The Platform Builder IDE has a built-in kernel debugger. You can launch this debugger by selecting the Build | Start Debug | Go menu item or by hitting the F5 key. The kernel debugger displays its output in the IDE output window under the Debug tab. You can view the output window by selecting the View | Output menu item. Then select the Debug tab.
Like downloading, debugging can occur over an Ethernet connection. It can also occur over the serial port. We'll choose the latter because it is easy to set up and use. A simple serial cable (not null modem) will do the trick. You can improve the debugger throughput by increasing the speed at which the debugger and target platform communicate over the serial port. On the workstation, select Build | Debugger | Remote Connection to view the Remote Connection dialog box. In the Connection list box, you must select Kernel Debugger Port and then click on Settings... (see Figure 3.12).
){kind=link}
Figure 3.12 Setting the kernel debugger port's speed
At the other end, the change in the default speed of the serial connection must be passed on Loadcepc. This is accomplished with the /B:115200 option. In addition, if you are using the S3 display drivers that are bundled with the CEPC, you must instruct Loadcepc to initialize the display adapter in 640_480 mode. This is done via the /D:2 option. Finally, Loadcepc must be told to expect the image to come down the parallel port, with the /P option.
Loadcepc /B:115200 /D:2 /P
You can request Loadcepc to use the serial port to download the binary image, provided that you set up CESH to do the same on the workstation. In this case, you specify the /Q option. The COM port to be used by Loadcepc is identified with an additional option, /C:{1 | 2}.
After you initiate the kernel debugger, the first messages in the debug window announce the handshaking between the debugger and the target:
Kernel debugger waiting to connect on com1 at 115200 baud Host and target systems resynchronizing...
When the debugger is started, you may get the erroneous error message shown in Figure 3.13. You can safely ignore this message. The IDE is simply trying to find an updated copy of welcome.exe in the wrong release directory, a throwback from the days of the Embedded Development Kit (EDK).
){kind=link}
Figure 3.13 Error message when the debugger is started
Let's review what we've done so far:
-
Created a new platform, Adam, based on the MAXALL configuration
-
Created a simple new application for Adam called welcome.exe that displays a "Hello World!" message in a dialog box
-
Connected the workstation and CEPC for downloading over the parallel port and debugging over the serial port
-
Downloaded the operating system image to CEPC and watched it boot on the CEPC
After the last step is completed, you should see a Handheld PC–like shell pop up, complete with a Windows CE task bar. Let's take our configuration for a spin. Select the Start button and then click on Run.... In the Run dialog box, type in "welcome.exe" and then click on OK. The shell will attempt to execute welcome.exe, a request that will be translated in the inner layers of the kernel into a request from CESH to load welcome.exe from the release directory on the workstation:
KernelLoader: Using PPFS to load file welcome.exe
PPFS stands for Portable Parallel File System, which supports loading on demand. On the target platform, you should see welcome.exe running and greeting the world in a dialog box. You can close welcome.exe by right-clicking on its icon in the task bar and selecting Close.
You can try out our rapid development technique by stopping the debugger, making a change to the string displayed by Welcome, and then building the project, restarting the debugger and executing welcome.exe from the Run dialog box on the target.
Debugging Capabilities of CESH
CESH is more than just a downloading utility. It is called the Windows CE Debug Shell Tool for a reason. After the download is over, CESH gives you a command prompt. You can type in a variety of commands at the prompt to get useful information from the kernel running on the target platform. Typing "?" retrieves a list of all the commands supported by CESH (see Table 3.4).
Table 3.4 Commands Supported by CESH
|
Command |
Options |
Function |
|
break |
|
Stops the kernel at the current line of execution. This command can be used to halt the kernel and set a new breakpoint. |
|
dd |
addr [<size>] |
Displays the contents of addr. The optional size argument tells the command how many bytes to display. |
|
df |
filename addr |
Writes contents of addr to the file specified by filename. |
|
|
[<size>] |
The optional size argument tells the command how many bytes to display. |
|
dis |
|
Tells the virtual memory manager to mark all discardable memory as available. |
|
gi |
proc |
Lists all the processes running on the target. Processes are created from executables by the operating system. |
|
|
thrd |
Lists all the threads running on the target. A process may have multiple threads. |
|
|
mod |
Lists all the modules loaded on the target. Modules are DLLs that are loaded by executables. Device drivers are DLLs loaded by device.exe (mostly); as such, they appear under the modules' listing. |
|
|
all |
Lists processes, threads, and modules. This is the default value for the gi command. |
|
kp |
pid |
Kills the process with process ID pid. |
|
mi |
kernel |
Displays detailed information on memory used by the kernel. |
|
|
full |
Displays memory maps used by all processes and modules in the system. |
|
run |
filename |
Runs the file specified by filename in batch mode. |
|
S |
process |
Starts a new process. This command is useful when you don't have a user interface on the target platform that can be used to start a process. The s command can also be used for rapid development because it supports load on demand via PPFS. |
|
zo |
|
Displays and modifies debug zones for a process or module. This command is discussed in more detail in Chapter 9. |
After booting Adam successfully on a CEPC, you can run the gi command from the CESH command prompt and observe output similar to that shown in Listing 3.2. When executing welcome.exe, you will notice it listed as a process. The gi command prints out information that is used not just for debugging, but also for indexing other commands. For example, the process or module index, a number prefixed by either P or M, is passed to the zo command to identify the entity whose debug zone is being displayed or modified. Debug messages emitted by the kernel are prefixed with the address of the line that originated the message. You can map these addresses by looking at the pModule field of a module in the output of gi.
Listing 3.2 shows the processes running on the target platform. The file nk.exe is the Windows CE kernel process, filesys.exe manages the CE file system, the debug shell that communicates with CESH is shell.exe, device.exe loads and manages all the device drivers on the target platform, gwes.exe is responsible for creating and managing windows and messages, and finally, explorer.exe is the Handheld PC–like shell included in our image.
Listing 3.2 Running the gi command in CESH
Windows CE>gi PROC: Name hProcess: CurAKY :dwVMBase:CurZone THRD: State :hCurThrd:hCurProc: CurAKY :Cp:Bp:CPU Time P00: NK.EXE 00ffefe2 00000001 02000000 00000100 T Blockd 00ffdefe 00ffefe2 00000001 3 3 00:00:00.000 T Blockd 00ffe012 00ffefe2 00000001 7 7 00:00:00.082 T Blockd 00ffe31e 00ffefe2 ffffffff 2 2 00:00:00.005 T Blockd 00ffef1a 00ffefe2 00000001 1 1 00:00:00.063 P01: filesys.exe 00ffdaf6 00000002 04000000 00000000 T Blockd 00ffdb16 00ffdaf6 00000003 3 3 00:00:01.491 P02: shell.exe 00ffbd42 00000004 06000000 00000001 T Runing c0ffc942 00ffbd42 ffffffff 1 1 00:00:02.965 P03: device.exe 00ffb70a 00000008 08000000 00000000 T Sl/Blk 00eb5366 00ffb70a 00000009 2 2 00:00:00.081 T Blockd 00ff517e 00ffb70a 00000009 3 3 00:00:00.001 T Blockd 00ff551a 00ffb70a 00000009 3 3 00:00:00.004 T Sl/Blk 00ff7d56 00ffb70a 00000009 2 2 00:00:00.001 T Sl/Blk 20ff98ce 00ffb70a 00000009 2 2 00:00:00.132 T Blockd 20ff98ee 00ffb70a 00000009 2 2 00:00:00.000 T Blockd 00ffb72a 00ffb70a 00000009 3 3 00:00:03.026 P04: gwes.exe 00fd626e 00000010 0a000000 00000040 T Blockd 00f60e02 00fd626e 00000011 3 3 00:00:00.029 T Blockd 00f6200a 00fd626e 00000011 3 3 00:00:00.014 T Blockd 00f6230e 00fd626e 00000011 1 1 00:00:00.000 T Blockd 00f625f2 00fd626e 00000011 1 1 00:00:00.004 T Blockd 00f62a56 00fd626e 00000011 1 1 00:00:00.193 T Blockd 00f62b6a 00fd626e 00000011 1 1 00:00:00.046 T Sl/Blk a0f74386 00fd626e 00000011 1 1 00:00:00.291 T Sl/Blk 00fd628e 00fd626e 00000011 3 3 00:00:01.029 P05: explorer.exe 00f60c5a 00000020 0c000000 00000000 T Blockd 40ea6c02 00fd626e 00000031 3 3 00:00:01.769 T Blockd 00eb572a 00fd626e 00000031 3 3 00:00:04.446 T Blockd 00f60c7a 00f60c5a 00000021 3 3 00:00:00.430 MOD: Name pModule :dwInUSE :dwVMBase:CurZone M00: unimodem.dll 80eb5584 00000008 01160000 0000c000 M01: TAPI.DLL 80eb5ec0 00000008 01180000 0000c000 M02: SHLWAPI.dll 80f4e640 00000020 01060000 00000000 M03: IECEEXT.dll 80f4e810 00000020 01090000 00000000 M04: WININET.dll 80f4ed40 00000020 00f70000 0000c000 M05: imgdecmp.DLL 80f4ef44 00000020 00ed0000 00000000 M06: webview.dll 80f493ec 00000020 00e20000 00000000 M07: commctrl.dll 80f49c28 00000020 01520000 00000000 M08: CEShell.DLL 80f49ef8 00000020 00ef0000 00000000 M09: OLEAUT32.dll 80f60358 00000020 01390000 00000000 M10: ASForm.dll 80f627c8 00000020 00f50000 00000000 M11: kbdmouse.dll 80f62d78 00000010 00d20000 00000000 M12: DDI.DLL 80fd6b80 00000010 00d30000 00000003 M13: Redir.dll 80ff50c0 00000008 01110000 0000c001 M14: irdastk.dll 80ff6b78 00000008 011a0000 00008000 M15: netbios.dll 80ff76ec 00000008 010f0000 0000c000 M16: dhcp.dll 80ff7840 00000008 01220000 0000ffff M17: arp.dll 80ff7a20 00000008 01290000 00000001 M18: tcpstk.dll 80ff8250 00000008 011d0000 00000001 M19: ppp.dll 80ff8800 00000008 01340000 00000000 M20: CXPORT.dll 80ff89a0 00000008 01330000 0000c000 M21: AFD.Dll 80ff8c88 00000008 012a0000 00000000 M22: ole32.dll 80ff8f88 00000028 013d0000 00000000 M23: softkb.DLL 80ff9320 00000008 01500000 00000000 M24: WINSOCK.dll 80ff95a0 00000028 01310000 0000c000 M25: IRCOMM.DLL 80ff971c 00000008 01320000 0000c003 M26: irsir.dll 80ff9e74 00000008 00ce0000 0000c000 M27: NDIS.Dll 80ffa6bc 00000008 01270000 00000000 M28: msfilter.dll 80ffa810 00000008 00cb0000 00000000 M29: CEDDK.dll 80ffaef0 00000018 00da0000 00000000 M30: Serial.Dll 80ffb020 00000008 00cf0000 00000000 M31: toolhelp.dll 80ffbf68 00000004 015a0000 00000000 M32: coredll.dll 80ffe690 0000003f 015e0000 00000000 Windows CE>