Dear Dell,

I would like to share my deep frustration with your technical service process in Turkey. As of today, 54 days passed from the day I gave my out of the box faulty laptop to the technical service and until now, I haven’t received its money back, nor have I gotten a replacement.

Before going into detail, I would like to add that I was a happy Dell customer until experiencing this problem. I have bought several Dell products from USA, Germany and Turkey. I have started using your products about 10 years ago, and I am still using some of them at home. As a computer engineer, I have also recommended your products to my family and friends who required my assistance to choose the right computer. However, this problem showed that I couldn’t trust Dell in Turkey. I probably won’t ever buy any product of Dell in the future and I will also recommend against buying any Dell product in Turkey.

The whole story started when I ordered a new Dell Vostro laptop (Service Tag: 4Y6V002, Express Service Code: IM005059698) for my father from a web site called netsiparis.com. I ordered the laptop at 09.05.2014 and received the parcel at 12.05.2014. After unpacking the box, I quickly realized that something was wrong with the device. The monitor backlight was not working properly, most of the time it wasn’t working at all.

I directly contacted the customer service of the web site. The customer support told that I should contact the Dell technical service about my problem and gave the support number of Turkey.

The second step was calling the Dell technical service, but when I called them, I’ve learned that Dell in Turkey gave the technical service to a subcontractor called “Koc Sistem”, and technical service of Dell couldn’t help me.

The third step was calling Koc Sistem. Koc Sistem itself subcontracted the call service to another company called “Callus Bilgi ve İletişim Hizmetleri A.Ş.” (Multiple layers of subcontractors, a very “nice” way of supporting your customers). Still, they could be able to help me at that time by saying that I can send the laptop to the Koc Sistem center in Istanbul to have it analyzed. According to the call service, customers could also bring the computer to the service center themselves.

As I had bought the laptop for my father and visiting my parents, who live in another city, in 5 days, I decided to bring the laptop myself to speed up the process. At the service desk of Koc Sistem, I explained the issue and its urgency, made a quick demo, and added that I wanted a replacement of the laptop. Although service desk had immediately seen the problem, they couldn’t be able to help me quickly. Instead they explained the following “process” for the replacement:

• Accepting the laptop to the service desk
• Inspecting it once more by technical desk
• Technical desk reporting the error to Dell
• Waiting for Dell to approve the replacement
• Calling me after the paperwork is ready
• Me getting the defect laptop with the replacement paper
• Me sending both of them to netsiparis.com
• Finally getting the replacement

After returning from the Koc Sistem with my hands empty, I was a little bit sad. At that time, I still dumbly believed that all this process might complete in a couple of days because it was “out of the box” defect that we were talking about. Well, I couldn’t be more wrong!

The next 30 days passed by multiple calls of the call service and getting angrier after each call. According to the call service, the process stuck at Dell service approving the replacement.

At 12.06.2014, one day after the last stressing call with the call service, I received an e-mail from them. The e-mail explained that the Dell service finally approved the replacement and I should call Dell service (not Koc Sistem) to continue the process.

When I called the Dell service at 17.06.2014, I explained the technical service employee (Mr. C) about the situation, and asked what to do next. However, he told me that Dell Turkey hasn’t received anything about this issue up to that time point and the replacement hasn’t been approved yet. He asked me if I could send the e-mail sent by Koc Sistem about the Dell approval and told me that he will get in touch with me as soon as he gets information about the problem.

I waited 9 days for an update about this problem, but no one got in touch with me during this time period. By the way, instead of getting a replacement, I decided on getting a money refund, because if the replacement has any problems during its warranty period, I absolutely don’t want to re-experience whole this “support” process again.

After 9 days of waiting, yesterday (26.06.2014) I called the Dell technical service again. Another technical service employee (unfortunately I cannot remember his name) answered the phone. I explained him the whole story again and added that I immediately wanted to get my money back. He informed me that Mr. C tried to contact Koc Sistem about the issue but couldn’t get any replies. He told me that he can eliminate the Koc Sistem from this process (which should have done a long time ago) and offered me to send the replacement paper if I could send them a copy of the original receipt sent by netsiparis.com. He also informed me that Dell in Turkey could not send any money refunds to the customers; this issue was between the reseller and me. According to him, if I present the replacement paper of Dell to the netsiparis.com customer support, I can be able to get a refund.

As I didn’t want to accept his offer, I wanted to talk with someone who has more responsibility, thus got in touch with his team lead (Mr. O). I explained him the whole story again. Again, he told me the same thing about the money refund policy in Turkey and offered me to defend my rights in court if I want to insist on getting a money refund from Dell Turkey (a very “nice” way of solving the problem). After that, I accepted to get the paper from Dell and contact with netsiparis.com for the refund because I’ve already wasted a lot of time for this issue and don’t want spend any other effort other than sharing my complaints with you.

Since Mr. O refused to give the contact information of any other international Dell representatives with whom I can share my complaints directly, I’m sending this e-mail to you through him; he promised me to escalate the problem to Dell Europe and contact with me until 02.07.2014 to share its current status. But I would also be happy to get a reply directly from someone from a Dell representative outside Turkey.

I think I can also mention that I tried to contact Dell via Twitter at 05.06.2014 and got no replies from anyone to the following 3 tweets:

To sum up, I have sent a copy of the invoice along with all other e-mailings with Koc Sistem to Dell Turkey and still waiting for the paper. The defect laptop is still at Koc Sistem.  I’m not really sure if I can get a money refund from netsiparis.com just by presenting the paper. I’m also not sure if I have to visit Koc Sistem again to receive the defect laptop back.

I’m hoping to hear from you soon.

Best Regards,

Emin Şenay

P.S: A copy of this mail with some minor modifications such as removing the names of the representatives can be found at http://eminsenay.com/2014/06/dell-and-its-technical-service-disaster-in-turkey.

Emin Kategorilenmemiş Callus, Dell, Disaster, Frustration, Koc Sistem, netsiparis.com, Technical Service

WinCE Tutorial – 6 – Running WinCE under Virtual PC – 2

Debugging

After establishing a connection between development image Visual Studio and WinCE test image, it is relatively easy to use debug facilities. In the following sections, an example Hello World application debugging and an example network driver (passthru) debugging will be explained.

User Mode Program Debugging

1. Create a new Hello World subproject to your solution (File → New → Subproject, WCE Console Application, A typical “Hello World” application).
2. Right click to your OSDesign and select “Build All Subprojects”. After building the subproject, Platform Builder will automatically create a new NK.bin.
3. Upload this new NK.bin to the test system. After WinCE boot, you can open the source code and set break points. To start the program, you have two options. The first one is starting the application directly from WinCE. HelloWorld.exe is normally located at Windows directory. To see the file, you first need to change the directory settings to see hidden files. The second option is running the application from Visual Studio. From Target → Run Programs you can see all programs currently available in WinCE. Select HelloWorld.exe from there and hit the Run button.

Kernel Driver Debugging

Passthru driver located under $(WINCEROOT)\PUBLIC\COMMON\OAK\DRIVERS\NETSAMP\PASSTHRU will be used as an example.

1. Copy the entire directory under $(WINCEROOT)\PLATFORM\VirtualPC\SRC\drivers. Create SRC and drivers directories. Create dirs files under src and drivers directories.
   Src directory dirs file content:

   DIRS= \

   drivers \

   drivers directory dirs file content:

   DIRS= \

   passthru \

   Modify the $(WINCEROOT)\PLATFORM\VirtualPC\dirs file by adding src directory as a line.

2. Change the $(WINCEROOT)\PLATFORM\VirtualPC\FILES\platform.reg file and add the following line:
   

   #include “$(_TARGETPLATROOT)\src\drivers\passthru\passthru.reg”

3. Change the $(WINCEROOT)\PLATFORM\VirtualPC\FILES\platform.bib file and add the following line:
   

   passthru.dll  $(_FLATRELEASEDIR)\passthru.dll    NK SHK

4. Enable KITL and kernel debugger from the project Build Options.
5. Rebuild the solution and load the generated NK.bin image to the test system.
6. In output window, you will start to see the passthru driver messages.
   
7. You can also set breakpoints to your code.Note: Sometimes the breakpoints do not become active although the dll is loaded. In this condition, starting a command line instance in WinCE magically solves the problem.

This was the last part of the WinCE tutorial series. I hope you enjoyed it!

Emin Kategorilenmemiş debugging, tutorial, Virtual PC, Windows Embedded CE 6.0

WinCE Tutorial – 5 – Running WinCE under Virtual PC – 1

Running the Image in Virtual PC

You can find the ready Virtual PC image under the VM directory of the packet downloaded from the internet. You can delete the .vfd file if you wish. This file is a floppy image for the bootloader. We will create our own image to see the kernel and driver debug messages using COM port.

Booting the Operating System

Local Install

You can follow the local install steps explained for VMware. This time, use your new NK.bin. You can mount an .iso image after running the virtual machine from the CD menu of the virtual machine window.

Remote Download&install Using Serial Connection

This install mode has not been tried yet but following the steps explained for Vmware will be sufficient to download and install the image using serial connection.

Note: Floppy image formats of vmware and virtualbox are different. Vmware can open .img and .flp images and can only create .flp images. Virtual PC can open .vfd, .img, .ima and .dsk images. However, the only difference of .flp and .ima is the file extension. .flp images created by Vmware can be renamed and used with Virtual PC.

Remote Download&install Using Ethernet Connection

We first need to set up a working network between Vmware development image and Virtual PC WinCE image. To keep the physical connections as few as possible, networking can be done using a virtual network adapter.

Steps for setting up a network are as follows:

1. Install Microsoft Loopback Adapter. It is explained here in detail.
2. Associate one of the Vmware networks with the loopback adapter. You can do this using Virtual Network Editor of Vmware.

1. Change the development vm network from the VMware image options to use the network with loopback adapter.

1. Manually configure the network settings of the development image as following:
   IP Address: 192.168.1.101
   Subnet Mask: 255.255.255.0
   Default Gateway: 192.168.1.1
2. Set up a dhcp server. An example with Tftpd32 will be explained here. After downloading it, copy it to the development vm and start the exe. Configure the program and the server like the following pictures.

   

   

   IMPORTANT: Using a dhcp server in a company network may cause problems. If you choose using the physical network instead of virtual one, you may need to establish a connection with static ip. It is explained here.

3. Set up the Virtual PC networking. Assign 2 cards (one of the cards will be used for debug communication and the other is for “normal” network). Change both adapters to Microsoft Loopback Adapter.
   
4. Prepare a new floppy image to boot Virtual PC VM. You can follow the steps written under Serial Connection for Vmware. After creating the floppy image, change the eboot.bin file with the one found under $(WINCEROOT)\PLATFORM\VirtualPC\BIN\BOOT. After that, unmount it and change the image file extension from .flp to .ima to use it with Virtual PC.
5. Start the Virtual PC image and capture the floppy image. If everything runs correctly, you will see the dhcp entry of the Virtual PC ethernet card in Tftpd32.
   
6. Open development image Visual Studio Connectivity Options. Choose Ethernet from the download and transport combo boxes. Click the settings button next to the download combo box. You will see the Virtual PC image in the Active target devices list. Select the device, apply the changes and return back to the ethernet
   
7. Shut down the WinCE image. Select “Attach Device” option from visual Studio → Target.  You will see a window like the following:
8. Start the WinCE image again. After a few seconds, download will be started. After download completes, you will see Windows Embedded CE 6.0 running in Virtual PC.
   

Connection with a Static IP

It is also possible to connect development and test systems without using a dhcp server. We must only start the ethernet bootloader with a static IP parameter. Boot the Virtaul PC vm with the floppy you created in the previous sections. Choose the clean boot option.

After that, start loadcepc.exe with eboot and give the static ip as a parameter.

Example:

A:\> loadcepc.exe /E:0:0:192.168.1.105 /L:800x600x16 eboot.bin

You can also change the floppy autoexec.bat and config.sys and add the static ip option. Modified files can be downloaded from here.

WinCE Tutorial – 7 – Running WinCE under Virtual PC – 3

Emin Uncategorized

WinCE Tutorial – 4 – Running WinCE under VMware – 3

Virtual PC – Creating and Running the CE Image

You need to install Virtual PC if you haven’t done it already. It can be found in this address.

Preparing the BSP and Creating the CE Image

A custom bsp specifically tailored for Virtual PC can be found in this address. After extracting the zip content, copy the vm directory to the host system and copy the other contents to the $(WINCEROOT)\platform directory of your development system. After doing that, open the visual studio of your development system. You can either create a new solution and select the new bsp from the wizard or change the bsp of your current solution. Detailed explanations of these operations can be found in previous sections of the tutorial.

You can also configure the bsp to use one of the ethernet cards directly as a debug card and the other one as a product ethernet card. To do this, follow these steps:

1. Set the following environment variables:
   KERNELNOSHAREETH = 1
   BSP_NOSHAREETH = 1
   
2. Open platform.reg file of the bsp and find the following lines:
   

   IF IMGNOKITL

   #include “$(_TARGETPLATROOT)\files\dc21x4.reg”

   ENDIF

   Change with

   ;IF IMGNOKITL

   #include “$(_TARGETPLATROOT)\files\dc21x4.reg”

   ;ENDIF

3. Open platform.bib file of the bsp and find the following lines:
   

   IF IMGNOKITL

   ndis_dc21x4.dll   $(_TARGETPLATROOT)\bin\drivers\$(WINCEDEBUG)\ndis_dc21x4.dll      NK SHK

   ENDIF IMGNOKITL

   Change with

   ;IF IMGNOKITL

   ndis_dc21x4.dll   $(_TARGETPLATROOT)\bin\drivers\$(WINCEDEBUG)\ndis_dc21x4.dll      NK SHK

   ;ENDIF IMGNOKITL

After those, rebuild the project and generate NK.bin.

If you skip these steps, vmini driver will be used if you enable KITL. You may still use normal ethernet functionality and debug the system at the same time. However, it is not recommended in this project because of the reasons mentioned here.

Note: You may encounter a problem about OAL.exe in the build process. This is because of an error in make files. You can change the makefile.def files of the kitl and oal to overcome this problem. The files can be found under:

$(WINCEROOT)\PLATFORM\VirtualPC\bin\kitl\makefile.inc

$(WINCEROOT)\PLATFORM\VirtualPC\bin\oal\makefile.inc

Find the line starting with “copy”, and change it with the appropriate lines given below:

copy $(_TARGETPLATROOT)\bin\oal\$(WINCEDEBUG)\oal.* $(_TARGETPLATROOT)\cesysgen\files\

copy $(_TARGETPLATROOT)\bin\kitl\$(WINCEDEBUG)\kitl.* $(_TARGETPLATROOT)\cesysgen\files\

After rebuilding the kitl and oal, nk.bin will automatically be created. However, in some of the build modes, this solution does not work. If this is the case, for a workaround, copy all files from $(WINCEROOT)\PLATFORM\VirtualPC\BIN\OAL\debug and $(WINCEROOT)\PLATFORM\VirtualPC\BIN\KITL\debug and paste them to the same directory you normally copy NK.bin from. Example directory path: C:\WINCE600\OSDesigns\OsDesign_VMware\OsDesign_VMware\RelDir\VirtualPC_x86_Release

Make sure that you copy the necessary files to your current solution directory.

Copy always contents from debug directory. After that, generate NK.bin by choosing “Make Run-Time” image option shown below.

WinCE Tutorial – 6 – Running WinCE under Virtual PC – 2

Emin Uncategorized

WinCE Tutorial – 3 – Running WinCE under VMware – 2

Debugging

Windows Embedded CE 6.0 has a standard set of debugging features such as breakpoints, step over, step in, etc. Kernel, drivers and applications can be debugged in this fashion. But first, a connection between the platform builder and the target system must be established.

Debugging in WinCE made possible by the Kernel Independent Transport Layer (KITL) functionality. Kernel mode code can only be debugged using KITL. Detailed information about the KITL can be found under this presentation video.

KITL can be used with different physical hardware such as COM, ethernet and usb. However, so called “transport” must be written for the hardware with which we want to connect. This “transport” can be thought of a special driver for KITL. In ethernet case, it is the edbg driver mentioned in the previous section. It is said that writing transport for KITL is easier than writing the original device driver.

In Vmware case, we don’t have any transports which we can use with KITL. Because of that, WinCE image running in Vmware cannot be debugged for the time being.

Note: Hardware used for KITL must be a separate hardware which won’t be used by the WinCE. For example, if a serial port is selected as a KITL transport medium, this port cannot be recognized by WinCE. In ethernet, although it is possible to use the same port for debugging and “normal” networking using vbridge library and vmini virtual adapter, we do not use it for two reasons. The first reason is the speed. These services introduce a new layer, which clearly affects the performance negatively. Secondly, since we will work with ethernet drivers, it is important for us to separate the debug environment with the environment which we are testing.

Detailed information about vbridge and vmini can be found in this address.

Customizing the WinCE image for VMware

The image built in the previous steps runs under VMware. However, some of the hardware won’t be supported. Luckily, support for the most of the VMware hardware can be given by selecting the necessary items from the catalog items view of your solution. Lastly, CEPC BSP should be modified to support the ethernet card.

To support monitor, keyboard, hdd and usb, make sure that your catalog items view matches the following two pictures:

To support the audio, select “Ensoniq ES1371 (Unified)”. Finally, to support the CD-Rom, part of the file $(WINCEROOT)\PUBLIC\COMMON\OAK\DRIVERS\BLOCK\ATAPI\atapipcicd.cpp should be commented out. The part to be commented out is given with this file. Changing the file will also affect other CE solutions that you have.

Note that the last two changes are not applied or tested for the time being. That means, the image we are creating will not support sound and cd-rom.

Supporting the ethernet card is a bit more difficult than that. The AMD PCNet virtual card (vlance) is not supported by the Windows CE 6.0 by default. To add the support, ethernet driver for the Windows CE must be made available for the BSP.

To keep the original CEPC BSP untouched, we can first clone it and modify the cloned BSP. This can easily be done from Visual Studio → Tools → Platform Builder for CE 6.0 → Clone BSP option.

After cloning, two catalog files must be changed. These are: $(WINCEROOT)\PLATFORM\<platform_directory>\CATALOG\1033\cepcstrings.pbcxml and $(WINCEROOT)\PLATFORM\<platform_directory>\CATALOG\1041\cepcstrings.pbcxml. Open them with an editor and search for CEPC(case insensitive) and change them with the name you gave for the new BSP.

For ethernet support, copy the pcntn4m.dll and pcnet.reg files into the $(WINCEROOT)\PLATFORM\<platform_directory>\FILES directory. The files can be found in the following zip file.

After that, some modifications must be made in platform.bib and platform.reg files. These files can be found under $(WINCEROOT)\PLATFORM\<platform_directory>\CESYSGEN\files directory. You can either change the files with the ones given with this file or compare them with the originals and insert the lines which are missing in the originals.

After that, restart the Visual Studio if it is still open and then from the catalog items view, deselect CEPC bsp and select the bsp you created now (can be found under third party). After the rebuild, the image created will support the ethernet, too. You can load the image with one of the methods discussed in the previous sections.

If the VM still does not support ethernet, make sure that you selected the following packages about networking:

WinCE Tutorial – 5 – Running WinCE under Virtual PC – 1

Emin Bilgisayar, WinCE Tutorial debugging, tutorial, Vmware, Windows Embedded CE 6.0

WinCE Tutorial – 2 – Running WinCE under VMware – 1

Running the Image in VMware

First, create a custom Virtual Machine with VMware Workstation 6 hardware and select Ms-Dos as the operating system.

You do not have to change anything else for now. You may change the disk size according to your needs.

Booting the Operating System

There are a couple of ways to boot the system and install the created CE image. These are:

• Local install
• Remote download & install using serial connection
• Remote download & install using ethernet connection

For all of the connections, an MS-DOS startup disk is always a requirement.

Local Install

To be able to install the nk.bin image locally, we need loadcepc.exe. It can be found under $(WINCEROOT)\PLATFORM\CEPC\SRC\BOOTLOADER\DOS\BOOTDISK.

In this install type, it is easy to use an MS-DOS boot cd instead of a floppy because of the empty space we can use. Created nk.bin can directly be included in the cd-rom and be loaded easily. If we have selected the floppy, we would have needed an another medium to load the generated image from.

MS-DOS boot CD can be created using the MS-DOS BootCD program. First, download the bootcd.zip from the site. After unpacking the file, copy the loadcepc.exe and generated nk.bin files under the CD directory.

After that, generate an MS-DOS iso file by running the Build-ISO.cmd. BootCD.iso file will be created by the application.

After creating the bootable cd, go to the VMware Virtual machine options of the MS-DOS image you created. Go to the CD/DVD options and use the ISO file you created.

Now, you are ready to start the MS-DOS VMware image. After starting, you will see a screen like below:

You can select 1. After that, go to the CD Drive (X) and start the Windows Embedded CE 6.0 by entering the command “loadcepc /L:800x600x16 nk.bin”.

The operating system should be ready after a couple of seconds.

Alternatively, you can use the attached Autoexec.bat and Config.sys to skip the command line parts and start the CE 6.0 automatically. You need to replace autoexec.bat and config.sys files located under the Floppy folder of the bootcd with the ones given with this zip file.

Remote Download&install Using Serial Connection

Windows CE image can also be downloaded from the developer computer automatically using the serial connection. Moreover, this can directly be done in Visual Studio. Required steps are as follows (Developer system is also a VMware OS in this example):

• Add 2 COM ports to the development and CE VMware images.
• Settings for development computer:
  • Use named pipe (\\.\pipe\com_1 and \\.\pipe\com_2)
  • This end is the client
  • The other end is a virtual machine

• Settings for CE:
  • Use named pipe (\\.\pipe\com_1 and \\.\pipe\com_2)
  • This end is the server
  • The other end is a virtual machine
  • Yield CPU on poll is selected.
• Open the Visual Studio project. From Target → Connectivity Options, choose the following options:
  • Target Device: CE Device
  • Download: Serial, settings → COM2, baud rate 115200, data bits 8, parity None, flow control None, stop bits 1.
  • Transport: Serial, settings → same as above.
  • Debugger: KdStub

• Apply and Close the window.
• Create a new HyperTerminal connection for debug messages coming from CE. Settings → COM1, 38400 bps, data bits 8, parity None, stop bits 1, flow control None.
• Create an MS-DOS boot disk using the floppy template shipped with platform builder. It is easier using a floppy image file instead of a physical drive. Navigate to the VMware development image settings (VM → Settings) and from the hardware tab, select floppy (if you don’t have a floppy disk, create one by selecting add). Select “use floppy image” file and create an image.

• Navigate to the %ProgramFiles%\Microsoft Platform Builder\6.00\CEPB\Utilities directory, and then run MakeImageDisk.exe.
• From the MakeImageDisk window, choose Open, and navigate to %ProgramFiles%\Microsoft Platform Builder\6.00\CEPB\Utilities, and choose CepcBoot.144. After that press start.
• Disconnect the floppy disk from development VM and connect it to the CE VM.
• Start the CE VM. From the boot menu, select  “Boot CE/PC (serial via sboot.bin)”

• From development VM visual studio, select “Attach Device” from the Target menu. Download window will be displayed shortly. You can check the Hyperterminal for any messages if anything goes wrong.

• After download completes, Windows CE will start automatically.

Remote Download&install Using Ethernet Connection

Normally, created nk.bin image can also be downloaded using the ethernet. However, this couldn’t be done for vmware because of a couple of reasons:

• Ethernet bootloader must recognize the ethernet device that is installed into the system. Ethernet bootloader shipped with the Platform Builder does not recognize any of virtual ethernet cards which are available for Vmware.There are 2 different virtual ethernet cards which can be used with Vmware. These are Amd Pcnet ethernet card and Intel e1000 gigabit ethernet card. For the first one, two different drivers, vlance and vmxnet, can be used under the supported operating systems. Vmxnet is the faster driver and is only available with Vmware guest additions, which is not available for Windows Embedded CE.In order to support the ethernet download capability, ethernet bootloader (eboot.bin) must be modified and linked with a special “edbg” driver written for the ethernet card. This driver is different than the normal ndis driver written for Windows CE 6.0.
• We currently don’t have edbg driver for any of the ethernet cards supported by Vmware.
• edbg driver code for some Amd and Intel cards is shipped with the Platform Builder, but even if the source code can be modified to work with vmware, it is non-trivial to generate an edbg driver .lib file which then must be linked to the bootloader.

WinCE Tutorial – 4 – Running WinCE under VMware – 3

Emin Uncategorized Vmware

WinCE Tutorial – 1 – Introduction & Installation

VMware – Creating and Running the CE Image

To make the explanation simple, we will first only try to run the image on Vmware. After that, we will modify the initial bsp to support the virtual hardware of Vmware.

Preparing the BSP and Creating the CE Image

After installing all the packages mentioned above, open the Visual Studio and create a new OS Design project.

Select CEPC based x86 project from the available BSPs.

Select Custom device from the design templates.

You can select what you want according to your needs in the following screens.

After creating the OS design project, build the OS. If you get an error about the large runtime image, you may allow the image size larger than 32 MB by selecting the IMGRAM64 option from the build options (for 64 MB) or define the related environment variable (IMGRAM128, IMGRAM256, IMGRAM512) for larger image sizes. Alternatively, you can remove some of the packages you selected before to lower the runtime image size.

After building the project, Visual Studio automatically generates a runtime image by default. The image file nk.bin can be found under the project folder (For example: C:\WINCE600\OSDesigns\OSDesign1\OSDesign1\RelDir\CEPC_x86_Release). If you cannot find it, right click the Visual Studio project select “Make Run-Time Image” from the list.

WinCE Tutorial – 3 – Running WinCE under VMware – 2

Emin Uncategorized

Edit after 7 years:Before starting to read these pages, please keep in mind that I stopped working on WinCE  (or any other embedded OS) a couple of months after preparing this tutorial. Unfortunately I don’t remember anything valuable other than the written contents of it. Therefore, I’ll most probably keep your support requests or questions unanswered.

A couple of months ago, we started a new project about a device driver for Windows Embedded CE 6.0. In this project, my first task was preparing a toolchain. We needed a running environment for the operating system and because of some reasons which I won’t mention here, we didn’t want to buy a real hardware. So, I started searching virtualization solutions. At first, I thought that it will be easy to find a running WinCE bsp for one of the virtual machines. After a dozen of unsuccessful Google searches, it started to be clear that I could not find an easy solution. After that, I started collecting some bits and pieces from many different web sites. Adding my own experience created this tutorial. Your comments and corrections are always welcome.

I also want to clarify why I’ve chosen English here: As I’ve written in my previous posts, I don’t normally write anything English into this blog. However, I decided to make an exception for this tutorial. First of all, most of this tutorial is already written in English and I don’t have enough time to translate it into Turkish. Secondly, it is very difficult to find a tutorial which covers all of the following sections written. Personally, I couldn’t find any. I thought that it can be better to publish all these information in English for a broader audience.

Ok, one more last thing: I am not responsible for any loss resulting from the use of this tutorial.

Toolchain

The development environment will look like the following schema:

The reason of developing in a VM instead of the host PC is keeping the native system clean. Also, snapshots can be taken and reverted back in the learning process if something goes terribly wrong. Note that some Platform Builder versions won’t work if installed side-by-side and may corrupt or even crash your installation.

To develop a Windows Embedded CE 6.0 image (NK.bin file), copy all device-specific sources from ClearCase into the Platform-Builder-Directories of the virtual machine. Make your changes and build an image.

To debug the image you created, set your create and configure a network for your development and test virtual machines. After that, you can transfer the generated data to your target-device and start debugging.

Following sections explain the development processes in detail.

Preparing the Environment for WinCE Development

There are a couple of steps to follow before starting application/driver development for Windows Embedded CE 6.0. These are:

1. Installing the required packages to development system.
2. Preparing the bsp and creating the CE image.
3. Running the image in target VM.

Second and third steps are dependent upon the target virtual machine we are using. You can think of different virtual machine programs as different physical machines which contain different hardware. Since bsp is created for a specific hardware platform, we need different bsps for different virtual machines.

For development system, Vmware is chosen as the virtual machine because of its advanced settings and speed. It has already been used for some other jobs by some of the developers of the team, which also affected the choice. We’ve already had the required license for the software (workstation), but it is theoretically possible to use the free alternatives VMware Player and VMX Builder.

For the test VM, VMware was tried first. After some effort, it was understood that debugging an application or a driver would be very difficult in Vmware because of the lack of ethernet debug drivers. Hence, Vmware WinCE images could only be debugged using trace messages, which is very uncomfortable.

As a second option, Virtual PC was taken into consideration. It was at first difficult to set up a working network between Vmware development system and Virtual PC test system in our corporate network. After setting up a functioning network, WinCE image could be loaded and debugged with the ethernet interface successfully.

In the following sections, both of the target virtual systems, as well as detailed information about the things done to support debugging using ethernet card in VMware will be explained. The user can choose one of the target systems. Note that two VMware images cannot be emulated using VMware Player at the same time.

Installing Packages

The following packages should be installed into the development computer for Windows Embedded CE Development:

• Install Visual Studio 2005 (Except Express Edition)
• Install Visual Studio 2005 SP1
• Install Visual Studio 2005 SP1 for Vista (If the development computer is Vista / Win 7)
• Install Windows Embedded CE 6.0 (Evaluation Edition)
• Install Windows Embedded CE 6.0 SP1
  
• Install Windows Embedded CE 6.0 R2
• Install Windows Embedded CE 6.0 cumulative product update package (through 12/31/2008)
• Install Windows Embedded CE 6.0 monthly update package (Jan 2009)
• Install Windows Embedded CE 6.0 monthly update package (Feb 2009)
• Install Windows Embedded CE 6.0 monthly update package (Mar 2009)
• Install Windows Embedded CE 6.0 monthly update package (Apr 2009)
• Install Windows Embedded CE 6.0 monthly update package (May 2009)
• Install Windows Embedded CE 6.0 monthly update package (June 2009)

Other monthly update packages may also be released at the time you are reading this document. Please check Microsoft download site and install all updates.

Note: At the time the original document was written, R3 hasn’t been released yet. You can directly install R3 after installing R2. R3 probably includes monthly updates given above.

Because of a proxy problem, one may not install the Windows Embedded CE 6.0 and R2 from the links above (It was the case for me). If you encounter a problem installing these packages, you have two options to overcome it:

1. Installing from the CD: Microsoft sends the Evaluation edition CDs without cost (except shipping) if requested.
2. Hacking the internet installation: The problem is that the setup tries to download some packages during install. If you have a proxy with authentication, setup cannot download the required packages and installation fails (probably because of a bug in the setup). If you can manually download the packages and put them under the same directory of the msi file of the setup, setup uses these files and installs the embedded cd without any problem. msi files of the Embedded CE and R2 are automatically created under temp (C:\Documents and Settings\<username>\Local Settings\Temp) directory after clicking the setup.exe downloaded from the links above. All packages that may be used in install process can be found here (Required files are extracted from the msi files by opening them with Orca Msi Editor). Depending on the checkboxes you selected in the install process, actual required packages might be a subset of them. After downloading the files given above, just execute .msi files.

Installing the packages is straightforward. Only make sure that you installed x86 support. Installing “Shared source” may also be useful in the future.

WinCE Tutorial – 2 – Running WinCE under VMware – 1

Emin Kategorilenmemiş development environment, toolchain, WinCE