Blog

13th MVP Award!

I've been honoured with the Microsoft MVP Award again this year!

Congratulations! We are pleased to present you with the 2014 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Windows Embedded technical communities during the past year.

If my memory serves me right, this is now the 13th award in a row! Very happy to be recognized in the field again!

Both Michel Verhagen and Erwin Zwart of GuruCE are Microsoft Embedded Most Valuable Professionals; a recognition of their expertise and community involvement in the field of Windows Embedded Compact.

Windows Embedded Compact 2013 update out now!

The long awaited update for Windows Embedded Compact 2013 is now available for general download! The update now integrates Platform Builder and Application Builder with Visual Studio 2013. It also contains a (source) WiFi driver for the TI SDP44xx chipset, and a (source) BSP for the Freescale i.MX6 processor range.

More info here.

MSDN subscribers can download the new update iso through their subscription download center and the general public can obtain the update by registering and downloading here.

First look at Windows Embedded Compact 2013 running on Opal i.MX53

We are still finalizing the last bits of our Windows Embedded Compact 2013 (WEC2013) BSP, but here is a first look of the port on the Opal i.MX53 development kit:

GuruCE expert honoured with MVP award

MVP LogoGuruCE is proud to announce that Erwin Zwart, of our European branch, has been recognized by Microsoft for his technical excellence, community involvement and technical knowledge, and has received the Microsoft Most Valuable Professional (MVP) Award.

Congratulations Erwin!

Both Michel Verhagen (APAC branch) and Erwin Zwart (EMEA branch) are now MVPs, showcasing GuruCE's expertise in all things related to Microsoft Embedded products.

Opal r289

We've just released Opal: r289.

We believe our BSP for the Device Solution Opal iMX53 Module and Development kit is the best WEC7 BSP available for the Freescale iMX53 CPU. We have fixed many bugs in Freescale's stock code and added many new features, like for instance WIFI, full featured ECSPI drivers, GPIO drivers, etc.

The complete changelist can be found in the release notes.

Get Opal Release r289 now!

Note that the latest release can always be found at this link: http://guruce.com/opal/release/latest

No more SYNCHRONIZE_DRAIN!

Most BSPs use the SYNCHRONIZE_DRAIN and SYNCHRONIZE_BLOCK macros to serialize the build process on multiprocessor machines. Since almost all machines are multi-processor (or hyperthreading) nowadays, these macros really have to be used.

SYNCHRONIZE_DRAIN and SYNCHRONIZE_BLOCK work on the entire build tree, so if module "A" has the SYNCHRONIZE_DRAIN macro set in its sources file this module won't be build until all other modules in the entire build tree have been built, even if module "A" was only depending on one other module.

You can see that the brute force method of SYNCHRONIZE_DRAIN and SYNCHRONIZE_BLOCK can really slow down your build performance.

Luckily, there are some better macros we can use that provide a much more granular method of serializing the build system: BuildPassName_PRODUCES and BuildPassName_CONSUMES. These macros are now finally well documented in MSDN for WEC2013.

The usage of these macros is very easy and better to understand than the SYNCHRONIZE_DRAIN and _BLOCK macros:

The directory with a Sources file that contains a BuildPassName_PRODUCES macro with a particular value will be built before any directories with a corresponding BuildPassName_CONSUMES macro value. This build order happens regardless of the directories' position in the Dirs File.

In other words:

If module "A" needs module "B" to link, then module "B" has to add LINK_PRODUCES=B to its sources file and module "A" has to add LINK_CONSUMES=B to its sources file. This way module A won't be linked to module B before module B is built but any other non-dependent modules will continue to build in parallel. Easy as that!

You can specify multiple modules by separating them with a space:

LINK_CONSUMES=A B C D

Make sure to use unique names throughout your BSP tree, or build errors will result.

Freescale i.MX53 ECSPI silicon bug

We recently did a full rewrite of the Freescale ECSPI driver for our Opal i.MX53 BSP (now fully supporting all ECSPI features; master/slave mode, DMA, etc) and during testing we discovered a rather big problem with the ECSPI module inside the i.MX53...

For future reference and to prevent others from having to go through the same time-consuming research and analysis we decided to publish our findings through this blog post.

Problem Analysis

The ECSPI module shows unexpected behaviour when the bitcount is set to [(32 * n) + 1], where [n > 0].

As an example, let's walk through sending 1 x 33 bits.

In this case, we have to load the TXIFO with 2 UINT32s. The first UINT32 value contains 1 LSB and the 2nd UINT32 contains the remaining 32 bits.

For this transaction you'd have to configure the ECSPI registers as follows (33 bits, master mode, SS1, DRCTL don't care, loopback enable, no DMA, enable TC interrupt):

CONREG BURSTLENGTH      = 32
CONREG CHANNELSELECT    = 1
CONREG DRCTL            = 0
CONREG PREDIVIDER       = 0
CONREG POSTDIVIDER      = 0
CONREG CHANNELMODE      = 2
CONREG SMC              = 0
CONREG XCH              = 0
CONREG HT               = 0
CONREG EN               = 1

CONFIGREG HTLENGTH      = 0
CONFIGREG SCLKCTL       = 0
CONFIGREG DATACTL       = 0
CONFIGREG SSPOL         = 2
CONFIGREG SSCTL         = 2
CONFIGREG SCLKPOL       = 2
CONFIGREG SCLKPHA       = 0

INTREG TCEN             = 1
INTREG ROEN             = 0
INTREG RFEN             = 0
INTREG RDREN            = 0
INTREG RREN             = 0
INTREG TFEN             = 0
INTREG TDREN            = 0
INTREG TEEN             = 0

DMAREG RXTDEN           = 0
DMAREG RXDMALENGTH      = 0
DMAREG RXDEN            = 0
DMAREG RXTHRESHOLD      = 0
DMAREG TEDEN            = 0
DMAREG TXTHRESHOLD      = 0

STATREG TC              = 0
STATREG RO              = 0
STATREG RF              = 0
STATREG RDR             = 0
STATREG RR              = 0
STATREG TF              = 0
STATREG TDR             = 1
STATREG TE              = 1

PERIODREG CSDCTL        = 0
PERIODREG CSRC          = 0
PERIODREG SAMPLEPERIOD  = 0

TESTREG LBC             = 1
TESTREG RXCNT           = 0
TESTREG TXCNT           = 0

Load the TXFIFO with 2 UINTs as follows:

[0] 0x00000001
[1] 0xAAAAAAAA

The STAT & TEST registers reflect this:

STATREG TC              = 0
STATREG RO              = 0
STATREG RF              = 0
STATREG RDR             = 0
STATREG RR              = 0
STATREG TF              = 0
STATREG TDR             = 0
STATREG TE              = 0

TESTREG LBC             = 1
TESTREG RXCNT           = 0
TESTREG TXCNT           = 2

At this moment start the transfer by setting the XCH bit in the CONREG. This is when strange things start to happen:

CONREG BURSTLENGTH      = 32
CONREG CHANNELSELECT    = 1
CONREG DRCTL            = 0
CONREG PREDIVIDER       = 0
CONREG POSTDIVIDER      = 0
CONREG CHANNELMODE      = 2
CONREG SMC              = 0
CONREG XCH              = 0
CONREG HT               = 0
CONREG EN               = 1

CONFIGREG HTLENGTH      = 0
CONFIGREG SCLKCTL       = 0
CONFIGREG DATACTL       = 0
CONFIGREG SSPOL         = 2
CONFIGREG SSCTL         = 2
CONFIGREG SCLKPOL       = 2
CONFIGREG SCLKPHA       = 0

INTREG TCEN             = 1
INTREG ROEN             = 0
INTREG RFEN             = 0
INTREG RDREN            = 0
INTREG RREN             = 0
INTREG TFEN             = 0
INTREG TDREN            = 0
INTREG TEEN             = 0

DMAREG RXTDEN           = 0
DMAREG RXDMALENGTH      = 0
DMAREG RXDEN            = 0
DMAREG RXTHRESHOLD      = 0
DMAREG TEDEN            = 0
DMAREG TXTHRESHOLD      = 0

STATREG TC              = 1
STATREG RO              = 0
STATREG RF              = 0
STATREG RDR             = 1
STATREG RR              = 1
STATREG TF              = 0
STATREG TDR             = 1
STATREG TE              = 1

PERIODREG CSDCTL        = 0
PERIODREG CSRC          = 0
PERIODREG SAMPLEPERIOD  = 0

TESTREG LBC             = 1
TESTREG RXCNT           = 4
TESTREG TXCNT           = 0

As you can see from the above, the XCH bit is clear (good!), the TC interrupt fired (good!), but the RXFIFO contains not 2, but 4 UINT32s!

At this moment RXFIFO contains:

[0] 0x00000001
[1] 0x00000001
[2] 0x00000001
[3] 0xAAAAAAAA

As you can see, the first UINT32 from the TXFIFO is duplicated twice at the beginning of the RXFIFO.

The situation is slightly different with the 65 bit case. In that case the TC interrupt never fires:

We load the TXFIFO with 65 bits as follows:

[0] 0x00000001
[1] 0xAAAAAAAA
[2] 0x55555555
CONREG BURSTLENGTH      = 64

TESTREG LBC             = 1
TESTREG RXCNT           = 0
TESTREG TXCNT           = 3

All other registers are the same as per above.

Now we start the transfer by setting the XCH bit in the CONREG. This is when more strange things start to happen:

CONREG BURSTLENGTH      = 64
CONREG CHANNELSELECT    = 1
CONREG DRCTL            = 0
CONREG PREDIVIDER       = 0
CONREG POSTDIVIDER      = 0
CONREG CHANNELMODE      = 2
CONREG SMC              = 0
CONREG XCH              = 1
CONREG HT               = 0
CONREG EN               = 1

CONFIGREG HTLENGTH      = 0
CONFIGREG SCLKCTL       = 0
CONFIGREG DATACTL       = 0
CONFIGREG SSPOL         = 2
CONFIGREG SSCTL         = 2
CONFIGREG SCLKPOL       = 2
CONFIGREG SCLKPHA       = 0

INTREG TCEN             = 1
INTREG ROEN             = 0
INTREG RFEN             = 0
INTREG RDREN            = 0
INTREG RREN             = 0
INTREG TFEN             = 0
INTREG TDREN            = 0
INTREG TEEN             = 0

DMAREG RXTDEN           = 0
DMAREG RXDMALENGTH      = 0
DMAREG RXDEN            = 0
DMAREG RXTHRESHOLD      = 0
DMAREG TEDEN            = 0
DMAREG TXTHRESHOLD      = 0

STATREG TC              = 0
STATREG RO              = 0
STATREG RF              = 0
STATREG RDR             = 1
STATREG RR              = 1
STATREG TF              = 0
STATREG TDR             = 1
STATREG TE              = 1

PERIODREG CSDCTL        = 0
PERIODREG CSRC          = 0
PERIODREG SAMPLEPERIOD  = 0

TESTREG LBC             = 1
TESTREG RXCNT           = 5
TESTREG TXCNT           = 0

As you can see from the above, XCH stays set, the TC interrupt never fires and the TESTREG shows there are 5 UINT32s received in the RXFIFO (note that loopback is enabled!).

The contents of the RXFIFO are:

[0] 0x00000001
[1] 0x00000001
[2] 0xAAAAAAAA
[3] 0x00000001
[4] 0x55555555

As you can see, the 1st UINT32 from the TXFIFO is duplicated in the RXFIFO at position 0, 1 and 3.

The behavior is slightly different when doing the same but with SSCTL set to 0, but it's still not doing the right thing.

When doing a transfer of 33 bits with SSCTL set to 0, only 32 bits are sent:

Load TXFIFO with:

[0] 0x00000001
[1] 0xAAAAAAAA

Set XCH, wait for TC, result:

TXFIFO still contains:

[0] 0xAAAAAAAA

RXFIFO contains:

[0] 0x00000001
[1] 0x00000001

Note that SSCTL=0 works correct for bitcounts that are not [(32*n)+1] where [n>0].

Here are the scope captures of 32, 33, 34 and 35 bits, showing the i.MX53's bad behavior when transferring 33 bits:


yellow = chip select
blue = clock
purple = data

Freescale's response

We of course asked Freescale to verify this bug and they have. This is their response:

We are able to reproduce it. Unfortunately, there's no workaround for this error.

Other i.MX CPUs affected by this silicon bug?

We have verified the i.MX25 is NOT affected by this bug (but the i.MX25 contains an older version of the SPI block).
We have not been able to try our tests on the i.MX6 yet, but since the i.MX6 contains the exact same ECSPI block as the i.MX53, we suspect this issue will also be present on the i.MX6 series CPUs.

We have asked Freescale to update the errata sheets for the affected processor(s), but so far the erratas are silent about this issue.

More ECSPI silicon bugs?

Unfortunately; yes. Also the RX DMA TAIL mechanism (allowing non 32-word aligned DMA transfers to complete) does not work correctly. Here is the official response from Freescale:

We have confirmed this with the SDMA script owner. The script does not support the 32bytes unaligned DMA transfer.
This is a documentation bug. This will be corrected on documentation on next release.

Interesting way to solve silicon bugs... ;)

Conclusion

The ECSPI module inside the iMX53 CAN NOT BE USED for SPI transfers on 32 bit edges + 1.

When BURSTLENGTH is set to [(32 * n) + 1], the following happens:

For n = 0 (bitcount 1): All works fine!
For n = 1 (bitcount 33): TC interrupt fires, XCH bit clears, but more data than expected in RXFIFO (first UINT32 from TXFIFO duplicated).
For n > 1 (bitcount 65, 97, 129, etc): TC interrupt DOES NOT fire, XCH bit stays set, and also more data than expected in RXFIFO (first UINT32 from TXFIFO duplicated).

Windows Embedded Compact 7 and source control

A question that keeps coming back on the forums and from our customers that just start out with Windows Embedded Compact is; what files need to be put in source control, and which don't?

To answer this recurring question once and for all; here's a breakdown of all the files and folders that need to be put under version control, specific for Windows EC 7.

When putting files under source control you:

  1. Don't want to miss any file that is required for a successful build
  2. Don't want to add any file that is automatically generated by the build system
  3. Don't want to add any file that changes automatically every time you build

The last two would cause a new revision every time you build the kernel, which is normally not what you want; a new revision should only indicate changes YOU made.

With those rules in mind, here are the steps:

Windows Embedded Compact 7

First, clean up your BSP folder:

  1. Delete all obj folders from your BSP (eg C:\WINCE700\PLATFORM\Opal)
  2. The easiest way to do this is to search for obj using the search option of the standard Windows File Explorer. Then sort the search results so all obj folders are at the top, select them all (only select the obj folders, do not select any files!) and press the delete key. Once all obj folders are deleted another search for obj should not return anything.

  3. Delete all build.* files from your BSP
  4. The easiest way to do this is to search for build.* using the search option of the standard Windows File Explorer. Select all build*.dat, build.log, build.err and build.wrn files and press the delete key. Once all build.* files are deleted another search for build.* should not return anything.

  5. Delete all bldsys.* files from your BSP
  6. The easiest way to do this is to search for bldsys.* using the search option of the standard Windows File Explorer. Select all bldsys.log, bldsys.out, bldsys.err and bldsys.wrn files and press the delete key. Once all bldsys.* files are deleted another search for bldsys.* should not return anything.

You can now add the entire BSP folder to source control.

The next thing to add is any SOC folders your BSP may need to build correctly. In case of the Opal, we use SOC folders COMMON_FSL_V3 and MX53_FSL_V3 located in \WINCE700\PLATFORM\COMMON\SRC\SOC.

First, clean up these folders:

  1. Delete all obj folders from any SOC folder your BSP uses (eg C:\WINCE700\PLATFORM\COMMON\SRC\SOC\COMMON_FSL_V3)
  2. The easiest way to do this is to search for obj using the search option of the standard Windows File Explorer. Then sort the search results so all obj folders are at the top, select them all (only select the obj folders, do not select any files!) and press the delete key. Once all obj folders are deleted another search for obj should not return anything.

  3. Delete all build.* files from any SOC folder your BSP uses
  4. The easiest way to do this is to search for build.* using the search option of the standard Windows File Explorer. Select all build.dat, build.log, build.err & build.wrn files and press the delete key. Once all build.* files are deleted another search for build.* should not return anything.

  5. Delete all bldsys.* files from any SOC folder your BSP uses
  6. The easiest way to do this is to search for bldsys.* using the search option of the standard Windows File Explorer. Select all bldsys.log, bldsys.out, bldsys.err and bldsys.wrn files and press the delete key. Once all bldsys.* files are deleted another search for bldsys.* should not return anything.

You can now add the SOC folders your BSP uses to source control.

Finally, you need to add your OS Design(s).

Again, first we clean up:

  1. Remove the .ncb and .suo files from your OS Design root folder (eg C:\WINCE700\OSDesigns\Opal)
  2. These files can be found in the root folder of your OSDesign (eg C:\WINCE700\OSDesigns\Opal\Opal.ncb). The .ncb and .suo files are generated by Visual Studio every time you open the OS Design.

  3. Remove the .pbxml.user file from your OS Design subfolder (eg C:\WINCE700\OSDesigns\Opal\Opal)
  4. This is a file (eg C:\WINCE700\OSDesigns\Opal\Opal\Opal.pbxml.user) generated by Visual Studio every time you open the solution.

  5. Remove the RelDir folder (eg C:\WINCE700\OSDesigns\Opal\RelDir)
  6. This is the folder that will hold all files generated when your build your OS Design build configurations. The entire folder and its subfolders needs to be deleted.

  7. Remove the folder Wince700 from your OS Design subfolder (eg C:\WINCE700\OSDesigns\Opal\Opal\Wince700
  8. This folder contains the sysgenned files that will be generated every time you sysgen your OS Design. The entire folder and its subfolders needs to be deleted.

  9. Delete all obj folders from your OS Design subfolder (eg C:\WINCE700\OSDesigns\Opal\Opal)
  10. The easiest way to do this is to search for obj using the search option of the standard Windows File Explorer. Then sort the search results so all obj folders are at the top, select them all (only select the obj folders, do not select any files!) and press the delete key. Once all obj folders are deleted another search for obj should not return anything.

  11. Delete all build.* files from your OS Design subfolder (eg C:\WINCE700\OSDesigns\Opal\Opal)
  12. The easiest way to do this is to search for build.* using the search option of the standard Windows File Explorer. Select all build.dat, build.log, build.err & build.wrn files and press the delete key. Once all build.* files are deleted another search for build.* should not return anything.

You can now add your OS Design to source control.

This concludes the steps required to successfully put all files required for a successful Windows Embedded Compact 7 build under source control.

To build a clean version out of source control perform the following steps:

  1. Make sure you have committed all your changes
  2. Remove your BSP folder
  3. Remove any SOC folder your BSP uses
  4. Remove the OS Design
  5. Now checkout all the files from source control into your WINC700 tree
  6. Open the OS Design solution and immediately close Visual Studio again.
  7. This action creates the RelDir folder and allows a command line build.

  8. Right click the OSDesign pbxml (one folder higher), hover over Open Build Window and click on the build configuration you want to build
  9. In the DOS box, type blddemo -q
  10. NEVER EVER forget -q (as that would be the demonic Build and Sysgen command)!!!
    You may want to set the DOS box windows properties to a bigger window and bigger buffer. I usually set the Layout to 150/9999 for buffer size and 150/50 for window size. I also enable QuickEdit mode (on the Options tab).

Windows CE 6.0 and source control

A question that keeps coming back on the forums and from our customers that just start out with Windows CE is; what files need to be put in source control, and which don't?

To answer this recurring question once and for all; here's a breakdown of all the files and folders that need to be put under version control, specific for Windows CE 6.0 (including R2/R3).

When putting files under source control you:

  1. Don't want to miss any file that is required for a successful build
  2. Don't want to add any file that is automatically generated by the build system
  3. Don't want to add any file that changes automatically every time you build

The last two would cause a new revision every time you build the kernel, which is normally not what you want; a new revision should only indicate changes YOU made.

With those rules in mind, here are the steps:

Windows CE 6.0

First, clean up your BSP folder:

  1. Delete all obj folders from your BSP (eg C:\WINCE600\PLATFORM\Topaz)
  2. The easiest way to do this is to search for obj using the search option of the standard Windows File Explorer. Then sort the search results so all obj folders are at the top, select them all (only select the obj folders, do not select any files!) and press the delete key. Once all obj folders are deleted another search for obj should not return anything.

  3. Delete all build.* files from your BSP
  4. The easiest way to do this is to search for build.* using the search option of the standard Windows File Explorer. Select all build.dat, build.log, build.err & build.wrn files and press the delete key. Once all build.* files are deleted another search for build.* should not return anything.

  5. Remove *.bif your BSP folder
  6. .bif files are only generated in the root of your BSP (eg C:\WINCE600\PLATFORM\Topaz), so just select the BSP folder in the standard Windows File Explorer and delete any .bif files from there.

  7. Remove folders lib and target from your BSP
  8. These folders contain the libraries (lib) and executables (exe and dll) that result from building your BSP and are generated in the root of your BSP folder (eg C:\WINCE600\PLATFORM\Topaz).

  9. Finally remove the folder CESYSGEN\files from your BSP
  10. This folder contains the sysgenned files that will be generated every time you sysgen your BSP. Do not delete the CESYSGEN folder itself, just the files subfolder of the CESYSGEN folder needs to be deleted.

You can now add the entire BSP folder to source control.

The next thing to add is any SOC folders your BSP may need to build correctly. In case of the Topaz, we use SOC folders COMMON_TOPAZ_V1 and MX25_TOPAZ_V1 located in \WINCE600\PLATFORM\COMMON\SRC\SOC.

First, clean up these folders:

  1. Delete all obj folders from any SOC folder your BSP uses (eg C:\WINCE600\PLATFORM\COMMON\SRC\SOC\COMMON_TOPAZ_V1)
  2. The easiest way to do this is to search for obj using the search option of the standard Windows File Explorer. Then sort the search results so all obj folders are at the top, select them all (only select the obj folders, do not select any files!) and press the delete key. Once all obj folders are deleted another search for obj should not return anything.

  3. Delete all build.* files from any SOC folder your BSP uses
  4. The easiest way to do this is to search for build.* using the search option of the standard Windows File Explorer. Select all build.dat, build.log, build.err & build.wrn files and press the delete key. Once all build.* files are deleted another search for build.* should not return anything.

You can now add the SOC folders your BSP uses to source control.

Finally, you need to add your OS Design(s).

Again, first we clean up:

  1. Remove the .ncb and .suo files from your OS Design root folder (eg C:\WINCE600\OSDesigns\Topaz)
  2. These files can be found in the root folder of your OSDesign (eg C:\WINCE600\OSDesigns\Topaz\Topaz.ncb). The .ncb and .suo files are generated by Visual Studio every time you open the OS Design.

  3. Remove the .pbxml.user file from your OS Design subfolder (eg C:\WINCE600\OSDesigns\Topaz\Topaz)
  4. This is a file (eg C:\WINCE600\OSDesigns\Topaz\Topaz\Topaz.pbxml.user) generated by Visual Studio every time you open the solution.

  5. Remove the RelDir folder (eg C:\WINCE600\OSDesigns\Topaz\RelDir)
  6. This is the folder that will hold all files generated when your build your OS Design build configurations. The entire folder and its subfolders needs to be deleted.

  7. Remove the folder Wince600\cesysgen from your OS Design subfolder (eg C:\WINCE600\OSDesigns\Topaz\Topaz\Wince600\cesysgen)
  8. This folder contains the sysgenned files that will be generated every time you sysgen your OS Design. Do not delete the Wince600 folder itself, just the cesysgen subfolder of the Wince600 folder needs to be deleted.

  9. Remove the folder Wince600\BSP_CPU\sdk from your OS Design subfolder (eg C:\WINCE600\OSDesigns\Topaz\Topaz\Wince600\Topaz_ARMV4I\sdk)
  10. This folder contains the files to be included in the SDK that will be generated every time you build your BSP. Do not delete the Wince600 folder itself, just the sdk subfolder of the Wince600 folder needs to be deleted.

  11. Remove any file in the Wince600 folder
  12. This should just leave one folder named OAK

  13. Remove the folder Wince600\Topaz_ARMV4I\OAK\target and Wince600\Topaz_ARMV4I\OAK\lib from your OS Design subfolder (eg C:\WINCE600\OSDesigns\Topaz\Topaz\Wince600\Topaz_ARMV4I\OAK\target)
  14. This folder contains the resulting files from building your subprojects (so if you don't see them you don't have subprojects that generate either a library or an executable. Do not delete the OAK folder itself, just the target and lib subfolders of the Wince600\OAK folder need to be deleted.

  15. Remove any file in the Wince600\OAK folder
  16. This should just leave two folders named files and MISC

  17. Remove nlscfg.inf in the files folder (eg C:\WINCE600\OSDesigns\Topaz\Topaz\Wince600\Topaz_ARMV4I\OAK\target)
  18. This file is regenerated every time you open your OS Design.

  19. Remove any folder other than INTLTRNS in the files folder (eg C:\WINCE600\OSDesigns\Topaz\Topaz\Wince600\Topaz_ARMV4I\OAK\target)
  20. INTLTRNS contains the localized string translations. Any other folder will be regenerated.

  21. Delete all obj folders from your OS Design subfolder (eg C:\WINCE600\OSDesigns\Topaz\Topaz)
  22. The easiest way to do this is to search for obj using the search option of the standard Windows File Explorer. Then sort the search results so all obj folders are at the top, select them all (only select the obj folders, do not select any files!) and press the delete key. Once all obj folders are deleted another search for obj should not return anything.

  23. Delete all build.* files from your OS Design subfolder (eg C:\WINCE600\OSDesigns\Topaz\Topaz)
  24. The easiest way to do this is to search for build.* using the search option of the standard Windows File Explorer. Select all build.dat, build.log, build.err & build.wrn files and press the delete key. Once all build.* files are deleted another search for build.* should not return anything.

  25. Finally, edit your .sln file in your OS Design root folder (eg C:\WINCE600\OSDesigns\Topaz\Topaz.sln)
  26. An annoying bug in the Platform Builder plugin for Visual Studio 2005 is that it generates new GUIDs for the build configurations every time you open the solution file. This would cause a new revision in source control every time you open the OS Design (so without changing any files that would justify a new revision). To work around this bug always keep your .sln file clean:

    • Open the .sln file in Notepad (I recommend Notepad++) and remove all lines in between "GlobalSection(ProjectConfigurationPlatforms) = postSolution"
    • Now save the .sln file

    Now every time you commit your changes to the source control system, double check the changes in the .sln file. Normally nothing else but the GUIDs in between the postSolution section will change, so you can then just revert the changes back to the "clean" file in source control.

You can now add your OS Design to source control.

This concludes the steps required to successfully put all files required for a successful Windows CE 6.0 build under source control.

To build a clean version out of source control perform the following steps:

  1. Make sure you have committed all your changes
  2. Remove your BSP folder
  3. Remove any SOC folder your BSP uses
  4. Remove the OS Design
  5. Now checkout all the files from source control into your WINC600 tree
  6. Open the OS Design solution and immediately close Visual Studio again.
  7. When asked to save the solution click No. This action creates the RelDir folder and allows a command line build. You don't save the solution file to prevent the changing GUIDs in the solution file.

  8. Right click the OSDesign pbxml (one folder higher), hover over Open Build Window and click on the build configuration you want to build
  9. In the DOS box, type blddemo -q
  10. NEVER EVER forget -q (as that would be the demonic Build and Sysgen command)!!!
    You may want to set the DOS box windows properties to a bigger window and bigger buffer. I usually set the Layout to 150/9999 for buffer size and 150/50 for window size. I also enable QuickEdit mode (on the Options tab).

Topaz Release 822

We've just released another Topaz BSP release: r822. This release fixes issues in FlexCAN, GPIO, bootloader, LCD, SD and SDK headers and it adds the General Purpose Timers (GPT) SDK to the kernel.

See the release notes for a complete change list.

Starting with this release we have retired the Topaz Binary BSP. The Topaz Binary BSP was not very useful since most customers sooner or later needed to change pin muxing and without source this is impossible. We now offer the full Topaz Source BSP for free with any of our support contracts.

Get Topaz Release r822 now!

Note that the latest release can always be found at this link: http://guruce.com/topaz/release/latest

Opal Release 160

We've just released the initial version of the Opal: r160.

We believe our BSP for the Device Solution Opal iMX53 Module and Development kit is the best WEC7 BSP available for the Freescale iMX53 CPU at this moment. We have fixed many bugs in Freescale's stock code and added many new features, like for instance fully working WIFI! As far as we know we are supporting the only WEC7 board with (working) integrated 802.11 a/b/g/n WIFI on the market today.

The complete changelist is simply too long to list in this blog post, but have a look in the release notes if you are interested.

Get Opal Release r160 now!

Note that the latest release can always be found at this link: http://guruce.com/opal/release/latest

Topaz Release 706

We've just released another Topaz BSP release: r706. This release contains a fix for the low power mode of FlexCAN and adds support for UART4 and UART5 in the bootloader (for redirecting Windows CE debug output).

Here's the complete changelist (see also the release notes):

CE 6.0 R3 Release 706

  • Shorter timeout for NETUI when using a headless kernel
  • Added bootloader support for serial output on UART4 and UART5
  • Fixed issue with FlexCAN low power mode D4

Get Topaz Release r706 now!

Note that the latest release can always be found at this link: http://guruce.com/topaz/release/latest

Full featured WEC7 OS Design builds in 5-10 minutes

With the exponential growth of Windows Embedded Compact 7 kernel images unfortunately also the build time grows exponentially. I have always used VMWare Workstation to keep my Windows CE build environments separate (as side-by-side installations are not supported). Unfortunately, with WEC7 it felt like being back in Windows CE 3.0 days... In those days it was not the size of the kernel causing clean sysgen's to take over 40 minutes to build but it was slow hardware. I've always been able to keep build times below 25 minutes using VMWare and fast hardware, but with WEC7 this proved impossible. On my Core I5 2.6 Ghz with 16 MB DDR3 memory and a 7200 rpm SATA3 disk a WEC7 build inside a VM running Win7 took over 50 minutes!

To speed up the builds I have now invested in a separate laptop, configured specifically to build WEC7 kernels. It's an ASUS N55SF with an Intel® Core™ i7 2670QM/2630QM Processor, 6M cache, 4 cores/8 threads, 3.1 GHz and 8 GB DDR3 memory.

As you may know, processor speed is only one part of the equation with the other big factor being disk speed. I therefore invested in one of the fastest SSD's available at the moment: the OCZ Vertex 4: SATA 3, 6 GB/s, 2.5" SSD with a max of 120k IOPS and 550 MB/s read and 475 MB/s write speed. I chose the 512 GB version as it is the fastest and with the huge kernels and installation size of WEC7 you simply need the space.

Even with this hardware running a VMWare Win7 image a build still took 25 minutes; quite an improvement from the >50 minute builds on my Core I5 with 7200 rpm SATA 3 disk but still too long. I then decided to ditch VMWare and try a native install with the OS on the SSD, together with VS2K5 and WEC7 Platform Builder.

After speeding up the build system using the method described in this blog post, my builds are now 9 minutes for a reasonably feature rich WEC7 kernel (and <5 minutes for small headless kernels). Finally we're back in the 21st century again! It sure took some time and money to speed up WEC7 builds but if you are building a lot of kernels the investment will pay itself off after a couple of weeks!

Here's the full specification (of all components relating to build speed):

  • Intel® Core™ i7-2670QM Processor (6M Cache, up to 3.10 GHz)
  • Room for improvement here if you go for a desktop system.

  • DDR3 1333 MHz SDRAM
  • Room for improvement here if you go for a desktop system.

  • 512 GB OCZ Vertex 4: SATA 3, 6 GB/s, 2.5" SSD
  • The Patriot Wildfire is the fastest according to passmark.com but the OCZ Vetex 4 is unbeatable in price/performance.

  • OS: Windows 7 64 bit

Unfortunately side-by-side installation of Windows CE 6.0 and WEC7 is not supported, but I'd love to see how fast a CE 6.0 kernel will build on this machine... Under a minute?

Conclusion:

When building kernels with WEC7 it's worth to fork out some cash to speed up the builds if you are building lots of kernels (or if you just don't want to drink so much coffee on a day ;)

PS: All build times are Debug OS Designs, with shell and built with blddemo clean -q

Topaz Release 676

We've just released a major upgrade to the Topaz BSP. The main feature we added in this release is support for a boot splash screen. Due to the changes in memory layout you will need to install the new Topaz Flasher and this new Topaz Flasher can not be used with Topaz releases older than r676.

Here's the changelist:

CE 6.0 R3 Release 676

  • Changed version number and product name of Topaz SDK
  • Updated FlexCAN driver source
  • Now turning backlight off after 10 minutes (instead of 1 minute)
  • Fixed serial debug redirection in bootloader (now works)
  • Added boot splash screen support from NAND and SD
  • Added registry setting so NETUI times out quicker on headless configurations

Get Topaz Release r676 now!

Note that the latest release can always be found at this link: http://guruce.com/topaz/release/latest

Topaz Release 589

We've just release a new version of the Topaz Binary BSP, Image Binaries and SDK containing some bug fixes and improvements to the BSP.

Get Topaz Release r589 now!

Note that the latest release can always be found at this link: http://guruce.com/topaz/release/latest

Adding Bluetooth support to a WEC7 kernel

Recently I had to add Bluetooth support to a custom board running Windows Embedded Compact 7. The Bluetooth module was CSR compatible connected to UART2. To enable the driver for this module you'll have to add the following registry settings to platform.reg:

; @CESYSGEN IF CE_MODULES_BTHCSR
[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\Transports\BuiltIn\1]
    "driver"="bthcsr.dll"
    "flags"=dword:1
    "name"="COM2:"
    "baud"=dword:1c200
    "resetdelay"=dword:300
; @CESYSGEN ENDIF

You'll have to adjust the baudrate and COM port to match your configuration. The Bluetooth universal loader (SYSGEN_BTH) first looks for PnP devices (like USB/SDIO) and if it can't find any of those it will look for devices listed in the above Bluetooth\Transports\BuiltIn key in the order they are listed.

When I first added support for Bluetooth I just clicked all of the available items in the catalog:

  • Bluetooth Profile Management APIs (SYSGEN_BTH_BTHUTIL)
  • Bluetooth Stack with Universal Loadable Driver (SYSGEN_BTH)
  • Bluetooth HID - Keyboard (SYSGEN_BTH_HID_KEYBOARD)
  • Bluetooth HID - Mouse (SYSGEN_BTH_HID_MOUSE)
  • Bluetooth HS/HF and Audio Gateway Service (SYSGEN_BTH_AG)
  • Bluetooth PAN (SYSGEN_BTH_PAN)
  • Bluetooth Settings UI (SYSGEN_BTH_SETTINGS)

After rebuilding the OS Design the universal loader just did not want to load the driver I specified under the Bluetooth\Transports\BuiltIn key. Without (premium shared) source code of the universal loader it was very difficult to find out what was going wrong. All I could go on was the debug messages outputted by the Bluetooth Module, which I enabled by adding this key to the device's registry (in OSDesign.reg):

; Debug Zones
[HKEY_LOCAL_MACHINE\DebugZones]
        "BTD"=dword:E404

Unfortunately the debug messages did not give any clue as to why it did not want to load the driver I specified. In the end I decided to just select the Universal Loadable Driver (SYSGEN_BTH) in the catalog and deselect everything else, just to get rid of all other unrelated Bluetooth messages. To my surprise all of a sudden the driver did load!

I copied the reginit.ini from the release folder to a temporary folder, selected all Bluetooth components again and rebuilt the kernel. I then compared the reginit.ini of the kernel with only the universal loader component selected with the reginit of the kernel with all Bluetooth components selected. That way I discovered the culprit component was the Bluetooth Profile Management APIs (SYSGEN_BTH_BTHUTIL) component.

This component adds the following registry settings:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\sys]
   "Power"=dword:0                  ; Radio off by default
   "ScanMode"=dword:0               ; Radio is not discoverable
   "DisableAutoSuspend"=dword:1     ; Allow suspend when connected

This disables the radio by default, hence the driver did not load.

So, when you want to enable Bluetooth at boot and you include the Bluetooth Profile Management APIs component, you'll have to override these registry values either inside platform.reg or OSDesign.reg:

; @CESYSGEN IF CE_MODULES_BTD
; @CESYSGEN IF OSSVCS_MODULES_BTHUTIL
[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\sys]
   "Power"=dword:1                  ; Radio on by default
   "ScanMode"=dword:3               ; Radio is discoverable
   "DisableAutoSuspend"=dword:1     ; Allow suspend when connected
; @CESYSGEN ENDIF OSSVCS_MODULES_BTHUTIL
; @CESYSGEN ENDIF CE_MODULES_BTD

WEDU endless loop in registration pages problem: solved

When I tried WEDU (the Windows Embedded Developer Update) I was never able to get past the pages where you have to register. After some back and forth with Microsoft it seems you HAVE to select "Yes, I agree" to the question "Do you agree that a Windows Embedded representative may contact you using the phone number or email address provided by you to supply further Windows Embedded Information", even though the options are "Please select from the Following Options", "Yes, I agree" and "No, I do not agree":

See also this forum post.

Initially I selected "No, I do not agree" because I do not want any unsolicited calls from Microsoft or one of my competitors ;). When you select that option WEDU does not throw any warning message, nothing in red, it just simply loops back to the registration page until you select "Yes, I agree".

I think this can be classified as a bug...

So, if you also encounter the WEDU endless registration loop problem; select "Yes, I agree" and say "No, I do not agree" out loud when you select it. That'll do it! :P

Hosting webservices on WEC using gSOAP: Windows Phone 7.5 Mango Client Application

In the previous 2 articles (this and this one) I showed you how to create .NET C# based client applications consuming a webservice running on a Windows Embedded Compact device. In this blog post I will show you how to do the same, but then with a client application running on Windows Phone 7.5!

Convert RPC/encoded to RPC/literal

When you try to use the existing wsdl file in a silverlight solution for WP7 you won't be able to use the operations as described. It seems that the silverlight version doesn't support RPC/encoded soap and ignores those operations. It does support RPC/Literal soap style so we need to change the style from RPC/encoded to RPC/literal. This is actually really easy: Open the wsdl file and modify the input and output operations from

<soap:body use="encoded" ..../>

to

<soap:body use="literal" ..../>.

In XMLSpy:

You can see that the HelloWorld_Binding, the middle part, has changed. The input and output body styles have been modified from encoded to literal. That's basically all you need to change. This change in the wsdl file requires us to modify and rebuild the server and client code. Let's start with the server side.

Rebuild HelloWorldWebService solution

Open the existing "HelloWorldWebService.sln" solution we created in the previous blog post.

  1. Right-click the wsdl file and choose “compile”.
  2. Now recompile our (regenerated) header file: Right-click on the HelloWsdl.h file and choose "compile". This will re-generate a bunch of files as well.
  3. Finally; build the solution...

Oops! Unresolved externals... The reason for these is that we changed the message style and therefore we need to construct (or actually gSOAP needs to construct) the soap message slightly different.

In the HelloWorldWebservice solution open HelloWsdlMethods.cpp and modify the content to match the following:

// int ns1__HelloWorldOperation(struct soap*, char *name, char* &answer)
int ns1__HelloWorldOperation(struct soap*, char *name, struct ns1__HelloWorldOperationResponse &_param_1)
{
        printf("Hello my method\r\n");
        char* myName = {"Erwin"};
        //answer = myName;
        _param_1.answer = myName;
        return SOAP_OK;
}

//int ns1__UploadResource(struct soap*, char *resourceName, xsd__base64Binary resource, unsigned int resourceId, unsigned int &resourceId_)
int ns1__UploadResource(struct soap*, char *resourceName, xsd__base64Binary resource, unsigned int resourceId, struct ns1__UploadResourceResponse &_param_2)
{
        printf("Upload resource called (name: %s, id: %d", resourceName, resourceId);
        int size = resource.__size;
        return SOAP_OK;
}

I commented the original code and added new code to emphasize the code differences.

Windows Phone 7.5 (Mango) Client application

Now lets create a Windows Phone 7.5 client application. Make sure you have the Windows Phone SDK 7.1 installed. You need this to build applications for WP7/7.5.

Open Visual Studio 2010 Express for Windows Phone and create a new application (File | New Project). In the C# section "Silverlight for Windows Phone" choose "Windows Phone Application":

Choose TestWebServiceWP7 as the solution name and leave the other options as is. Select "OK" to create the solution.
I'll leave the sample as simple as possible just to illustrate how to consume a webservice running on a Windows Embedded Compact device. Drag 2 buttons on the content panel. Name the first button "Test" and the other "UploadImage". Something like:

Double-click the test button so we can enter the code behind. First thing we need to do is add our (Web)Service reference. In the solution explorer right click on the "Service Reference" and choose "Add Service Reference". Select HelloWsdl, created in the beginning of this article. You should be seeing something like:

As you can see I named the service "HelloWsdlService". Click "OK" to add the web service to our solution. Add the following code to complete the Test button implementation:

namespace TestWebServiceWP7
{
    public partial class MainPage : PhoneApplicationPage
    {
        private HelloWsdlService.HelloWorld_PortTypeClient service = null;

        // Constructor
        public MainPage()
        {
            InitializeComponent();

            // Create service
            service = new HelloWsdlService.HelloWorld_PortTypeClient();

            // Event handler for asyn operation hello world
            service.HelloWorldOperationCompleted += new EventHandler<HelloWsdlService.HelloWorldOperationCompletedEventArgs>(HelloWorldOperation_Completed);
        }

        private void Test_Click(object sender, RoutedEventArgs e)
        {
            try
            {
                // Calling our webservice hello world
                service.HelloWorldOperationAsync("Erwin");
            }
            catch (Exception ex)
            {
                // Handle errors here
            }
        }

        void HelloWorldOperation_Completed(Object o, HelloWsdlService.HelloWorldOperationCompletedEventArgs args)
        {
            PageTitle.Text = args.Result.ToString();
        }
               
    }
}

As you can see I create the service class and the event handler which handles the HelloWorldOperation asynchroneously in the constructor. The button test code (Test_Click) calls HelloWorldOperation. Deploy your solution to either the WP7 emulator or to your Windows Phone device. Run the webservice code on the Topaz (as describer in the other articles) and run the application on the WP7 emulator or device.

To illustrate the complete solution check out this video showing me uploading and running the Windows Phone 7 application and the webservice on the Topaz. It is a recording of my desktop (I am using Cerdisp and Cerhost as an RDP solution to show the desktop of the Windows Embedded Compact device):

If you have any questions please leave a comment below!

Reconstructing WEC7 web updates for offline installation

[UPDATE: This issue has been resolved through the "Offline Layout" feature]

Microsoft changed the update mechanisms in the new version of Windows CE; Windows Embedded Compact 7. The update mechanism definitely needed an update, but in my humble opinion Microsoft made it worse instead of better...

We now have WEDU, the Windows Embedded Developer Update, a great idea if it would work. WEDU simply does not work inside a VMWare virtual machine and even if it works it always downloads the updates without a possibility to install from previously downloaded update packages.

That doesn't really matter if you have only 1 installation to keep updated, but what if you have multiple? Downloading gigabytes of data multiple times might not be time consuming or costing a lot of money in places where internet is fast and uncapped, but here in NZ internet is slow, expensive and capped so I really only want to download once and install often (see also this and this post).

If you have access to the Mobile & Embedded Communications Extranet (ECE) you can download most updates in img format, but unfortunately not all updates include all files needed and thus they are still web installers.

Luckily there are ways to reconstruct web installers so that you only have to download once and install (offline) often.

As an example we'll take the Windows Embedded Compact 7 Monthly Update July 2011:

  1. Download WindowsEmbeddedCompact7.exe
  2. Delete all subfolders under C:\Documents and Settings\All Users\Application Data\PkgCache
  3. Run the update
  4. When asked for a location for the files, click the box "Allow downloading for all files" and the click button "Download"
    NB: Everything from the OS, CTK and PB locations (see tree structure below) can be copied directly from the original WEC7 DVDs or you can point the installer to the DVD
  5. Once the download is finished you'll find the downloaded files in a GUID named subfolder of the PkgCache folder (full path above)
  6. Copy the downloaded files to a subfolder named "1" in the folder you placed WindowsEmbeddedCompact7.exe
  7. Continue the installation (NOTE: Do NOT exit the installation at any time before you have copied the files from the PkgCache folder! When you exit the update application ALL downloaded files will be deleted!)
  8. Repeat the steps above and increase the number of the subfolder you copy the files in for every component downloaded
  9. Once all components are downloaded and copied, exit the update application before it starts installing
  10. Restart the update application
  11. It will ask again for the missing files. Take note of the path it is showing in the box, for instance: [.]\OS\Common\Common.msi (for Architecture Common files)
  12. Rename the subfolder to match the expected location. So if you copied the common architecture update files into subfolder "4" you recreate the expected location (".\OS\Common") and move the files there
  13. Do this for all components and press OK
  14. The installer should then find the files and check if they are correct
  15. If all the files are in their correct places the installer does not show a download dialog anymore but instead will directly show a "Begin Install" window
  16. You can now run the installer for multiple (offline) installations

For reference, this is the entire directory tree required for offline installation of the July 2011 WEC7 update:

+---CTK (***)
+---OS (***)
|   +---Common
|   +---processor
|   |   +---ARMV5
|   |   +---ARMV6
|   |   +---ARMV7
|   |   +---MIPSII
|   |   +---MIPSII_FP
|   |   \---x86
|   \---sharedsource
+---PB (***)
+---Update1
|   \---Documentation
\---Update2
    \---OS
        +---processorconfig
        |   +---armv5
        |   |   +---checked
        |   |   +---debug
        |   |   \---retail
        |   +---armv6
        |   |   +---checked
        |   |   +---debug
        |   |   \---retail
        |   +---armv7
        |   |   +---checked
        |   |   +---debug
        |   |   \---retail
        |   +---MIPSII
        |   |   +---checked
        |   |   +---debug
        |   |   \---retail
        |   +---MIPSII_FP
        |   |   +---checked
        |   |   +---debug
        |   |   \---retail
        |   \---X86
        |       +---checked
        |       +---debug
        |       \---retail
        \---sharedsource

(***) This folder and all subfolders are copied from original WEC7 DVDs. You can also just point the installer to the DVD when asked for these files.

Hosting webservices on Windows Embedded Compact using gSOAP: Uploading a file

By popular demand here's a simple example how to upload a file using a gSOAP webservice. This is a follow up post; for this example you first need to read and implement the code from the first post in this series.

With the base code of the first post it is now very simple to extend that solution's functionality because we've already completed the most difficult part; setting up your solution.

In this follow up blog post I will create a method that allows you to upload a file to the Topaz target:

int UploadResource(String resourceName, byte[] resource, uint resourceId, uint &statusCode);

First we need to modify the existing wsdl file (our webservice design). I won't list the entire wsdl file here because it's getting a bit long. Instead I have downloaded a tool that allows me to graphically design my wsdl file; Altova XML spy. Altova XML spy is not a free tool but it is very nice to work with it. There may be some free tools that offer the same functionality as well (let me know if you find one). I opened the wsdl file we created in the previous blog post in this series and opened it in XML spy for modification. After modification it looks like this:

Note the port type "UploadResource" I added (left block under HelloWorld_PortType). I added the input parameters resourceName (String), resourceId (unsinged integer) and a byte buffer for the actual data (base64Binary). I also added an output parameter statusCode. In the code I am not doing anything with it, but I just put it there to illustrate an output parameter. To complete the wsdl design we need to add the encodingStyle and namespace fields for the binding (the middle part of the picture). Just copy'n'paste it from the HelloWorldOperation. For complete reference I've attached the wsdl file to this blog post. It's a good example how to construct your webservice interface. It also shows a wsdl file can get complicated very quickly so a design tool like the one I used is recommended.

Open the existing "HelloWorldWebService" solution we created in the previous blog post. You're now just a few simple steps away from finishing the server side code:

1). Right click the wsdl file and choose “Compile”. Now our header (HelloWsdl.h2). Right click on the HelloWsdl.h file and choose "compile". Again this will re-generate a bunch of files as well.

If you would now build your solution you will end up with some unresolved externals; our newly created method. You can find the declaration of this new method in the generated soapStub.h file:

/******************************************************************************\
 *                                                                            *
 * Server-Side Operations                                                     *
 *                                                                            *
\******************************************************************************/

SOAP_FMAC5 int SOAP_FMAC6 ns1__HelloWorldOperation(struct soap*, char *name, char *&answer);

SOAP_FMAC5 int SOAP_FMAC6 ns1__UploadResource(struct soap*, char *resourceName, xsd__base64Binary resource, unsigned int resourceId, unsigned int &statusCode);

Open HelloWsdlMethods.cpp and add the following method implementation:

int ns1__UploadResource(struct soap*, char *resourceName, xsd__base64Binary resource, unsigned int resourceId, unsigned int &statusCode)
{
    printf("\r\nUpload resource called\r\nname: %s, id: %d ", resourceName, resourceId);
    return SOAP_OK;
}

Don't let the xsd__base64Binary type scare you. It's just a class with some members including:
__ptr: A character pointer to the memory buffer (char* buf) containing the contents of the file.
_size: Contains the number of bytes in the buffer above.

4). Build your solution and run the server code on your Topaz!

The C# Managed Client

In the previous blog post in this series we've created a Testclient application written in C# to test our webservice. Open the "TestWebServiceClient" solution. Add an OpenFileDialog control and a button control to the Form. Call the button something like UploadFile:

Double click on the newly added button which will create the button click event code behind. Now implement the event handler with the following content:

// Opens a file dialog and uploads the file selected
private void UploadFile_Click(object sender, EventArgs e)
{
  if (openFileDialog1.ShowDialog() == DialogResult.OK)
  {
    byte[] data = GetBytesFromFile(openFileDialog1.FileName);
   
    if(data.Length > 0)
    {
       uint id = 22;
       try
       {
         server.UploadResource(openFileDialog1.FileName, data, ref id);
       }
       catch (Exception ex)
       {
         MessageBox.Show("Failed to upload resource" + ex.Message);
       }
    }
 }
}

// Reads a file and returns the content as a byte[]
public static byte[] GetBytesFromFile(string fullFilePath)
{
  // this method is limited to 2^32 byte files (4.2 GB)
  FileStream fs = File.OpenRead(fullFilePath);
  try
  {
    byte[] bytes = new byte[fs.Length];
    fs.Read(bytes, 0, Convert.ToInt32(fs.Length));
    fs.Close();
    return bytes;
  }
  finally
  {
    fs.Close();
  }
}

Of course this is just a sample and you should take of security and parameter checking. In this sample I have left this stuff out just to keep it as simple as possible.

When you run the HelloWorldWebservice on the target device and run the C# Client sample on your pc, a file open dialog will appear when you click on the "Upload File" button. Select a file (I just selected desktop.ini) and it will upload the contents of that file to the webservice on the target.

If you implemented everything correctly you should be seeing the following output on the target:

That's it!

To recap: To modify or extend your webservice, create/modify the wsdl. Compile the wsdl file, compile the header file. Implement the native webservice. When that's done, modify your client by refreshing the imported wsdl file and you can call your new webservice.

Happy 2012 to all our readers!

FlexCAN usage example

Since we included our iMX FlexCAN driver in the iMX25 Topaz image binaries we have received a couple of requests for sample code, so here it is:

#include "DebugZones.h"
#include "FlexCANSDK.h"

#define CAN_BITRATE         (125*1000)  // 125 kHz
#define CAN_READ_INTERVAL   1000        // Set to INFINITE to wait forever for a CAN Frame
#define CAN_WRITE_INTERVAL   500

CRITICAL_SECTION gCS;
LPCWSTR DataToHexString(const PCAN_FRAME pCANFrame)
{
    static WCHAR szHexString[100];
    WCHAR szHexByte[7];
    EnterCriticalSection(&gCS);
    {
        szHexString[0] = 0;
        if (pCANFrame->btDataLen)
        {
            wsprintf(szHexByte, L"0x%02X", pCANFrame->btData[0]);
            wcscat_s(szHexString, _countof(szHexString), szHexByte);
            for (int i=1; i<pCANFrame->btDataLen; i++)
            {
                wsprintf(szHexByte, L", 0x%02X", pCANFrame->btData[i]);
                wcscat_s(szHexString, _countof(szHexString), szHexByte);
            }
        }
    } LeaveCriticalSection(&gCS);
    return szHexString;
}

DWORD WINAPI CANReadThread(LPVOID lpParameter)
{
    HANDLE hFinishEvent = (HANDLE)lpParameter;
    CAN_FRAME canFrame = {0};
    canFrame.bExtended = CAN_EXTENDED;  // Receive any extended frame
    LOGMSG(ZONE_INFO, L"CAN Read Thread initialized; waiting for %s CAN frames...\r\n", (CAN_EXTENDED == canFrame.bExtended) ? L"Extended" : L"Standard");
    do
    {
        if (ERROR_SUCCESS == FlexCANReadFrame(1, &canFrame, CAN_READ_INTERVAL, 0))
        {   // Convert data to string, copy the string and show received frame
            LPWSTR pszData = wcsdup(DataToHexString(&canFrame));
            if (canFrame.bExtended == CAN_EXTENDED)
                LOGMSG(ZONE_INFO, L"Read CAN frame with ID 0x%08X, Data: %s\r\n", canFrame.ui32ID, pszData);
            else
                LOGMSG(ZONE_INFO, L"Read CAN frame with ID 0x%03X, Data: %s\r\n", canFrame.ui32ID, pszData);
            // Clean up
            free(pszData);
        }
    } while (WAIT_TIMEOUT == WaitForSingleObject(hFinishEvent, 0));

    return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
    // Register with debug subsystem
    RETAILREGISTERZONES(NULL);

    InitializeCriticalSection(&gCS);

    HANDLE hFinishEvent = NULL;
    HANDLE hReadThread = NULL;
    for (;;)
    {   // Use loop for easy break-out error handling
        if (!FlexCANInit(1))
            break;

        DWORD dwBitrate = CAN_BITRATE;
        if (!FlexCANSetBitrate(1, &dwBitrate))
            break;
        LOGMSG(ZONE_INFO, L"Bitrate set to %d (requested %d)\r\n", dwBitrate, CAN_BITRATE);

        hFinishEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
        if (!hFinishEvent)
            break;

        // Create the read thread that will receive all CAN Frames
        hReadThread = CreateThread(NULL, 0, CANReadThread, (LPVOID)hFinishEvent, 0, NULL);
        if (!hReadThread)
            break;

        // Some time to see CAN Frames coming in
        Sleep(10000);

        CAN_FRAME canFrame = {0};
        for (int i=0; i<10; i++)
        {   // Send a couple of frames at highest priority (0)
            canFrame.bExtended = CAN_EXTENDED;
            canFrame.btData[0] = 0x10;
            canFrame.btData[1] = 0x11;
            canFrame.btData[2] = 0x12;
            canFrame.btDataLen = 3;
            canFrame.ui32ID = 0x12345678;
            DWORD dwRet = FlexCANWriteFrame(1, CAN_DATA, CAN_TXNOW, 0, &canFrame, 500);
            LOGMSG(ZONE_INFO, L"Frame with ID 0x%08X and data %s sent. Result: %d\r\n", canFrame.ui32ID, DataToHexString(&canFrame), dwRet);
            Sleep(CAN_WRITE_INTERVAL);
        }

        // Signal read thread to finish
        SetEvent(hFinishEvent);
        if (WAIT_OBJECT_0 != WaitForSingleObject(hReadThread, CAN_READ_INTERVAL*2))
            TerminateThread(hReadThread, 0);

        // And wait for a frame with ID 0x12345678 for 10 seconds (no other CAN frames are accepted during this time)
        canFrame.bExtended = CAN_EXTENDED;
        canFrame.ui32ID = 0x12345678;
        LOGMSG(ZONE_INFO, L"Waiting for extended frame with ID 0x%08X...\r\n", canFrame.ui32ID);
        DWORD dwRet = FlexCANReadFrame(1, &canFrame, 10000, 0x1FFFFFFF);
        LOGMSG(ZONE_INFO, L"Specific FlexCANReadFrame result: %d\r\n", dwRet);
        if (ERROR_SUCCESS == dwRet)
            LOGMSG(ZONE_INFO, L"Read CAN frame with ID 0x%08X, Data: %s\r\n", canFrame.ui32ID, DataToHexString(&canFrame));

        // Now read any frame (ui32IDMask set to 0)
        LOGMSG(ZONE_INFO, L"Waiting for extended frame with any ID...\r\n");
        dwRet = FlexCANReadFrame(1, &canFrame, 10000, 0);
        LOGMSG(ZONE_INFO, L"Unspecific FlexCANReadFrame result: %d\r\n", dwRet);
        if (ERROR_SUCCESS == dwRet)
        {   // Show received frame
            if (canFrame.bExtended == CAN_EXTENDED)
                LOGMSG(ZONE_INFO, L"Read CAN frame with ID 0x%08X, Data: %s\r\n", canFrame.ui32ID, DataToHexString(&canFrame));
            else
                LOGMSG(ZONE_INFO, L"Read CAN frame with ID 0x%03X, Data: %s\r\n", canFrame.ui32ID, DataToHexString(&canFrame));
        }

        // Now transfer a whole bunch of messages in one go
        CAN_TRANSFER_BLOCK canBlock;
        canBlock.dwNumPackets = 32;
        canBlock.pCANPackets = new CAN_PACKET[canBlock.dwNumPackets];
        if (canBlock.pCANPackets)
        {
            for (DWORD i=0; i<canBlock.dwNumPackets; i++)
            {   // Init packets; data from max to 0
                canBlock.pCANPackets[i].bRemote = CAN_DATA;             // Data frame
                canBlock.pCANPackets[i].btIndex = 0xFF;                 // Let driver find a free message buffer
                canBlock.pCANPackets[i].btPriority = 0;                 // Highest priority
                canBlock.pCANPackets[i].bTxOnRemoteRx = CAN_TXNOW;      // Transfer immediately
                canBlock.pCANPackets[i].bWrite = CAN_WRITE;             // We want to write this frame
                canBlock.pCANPackets[i].canFrame.bExtended = CAN_STANDARD;  // Standard address (11 bit)
                canBlock.pCANPackets[i].canFrame.btData[0] = (BYTE)(0xFF - (i*(256/canBlock.dwNumPackets)));
                canBlock.pCANPackets[i].canFrame.btDataLen = 1;         // 1 byte data
                canBlock.pCANPackets[i].canFrame.ui32ID = 0x123;        // Address
                canBlock.pCANPackets[i].dwTimeout = 100;                // Write timeout
            }
            BOOL bRet = FlexCANTransfer(1, &canBlock);
            LOGMSG(ZONE_INFO, L"FlexCANTransfer result: %s\r\n", bRet ? L"TRUE" : L"FALSE");
            for (DWORD i=0; i<canBlock.dwNumPackets; i++)
                LOGMSG(ZONE_INFO, L"Individual transmit %d transmit result: %d\r\n", i, canBlock.pCANPackets[i].dwError);
        }

        // Now write a frame after receiving a remote request with the same ID
        canFrame.bExtended = CAN_EXTENDED;
        canFrame.btData[0] = 0x12;
        canFrame.btData[1] = 0x11;
        canFrame.btData[2] = 0x10;
        canFrame.btDataLen = 3;
        canFrame.ui32ID = 0x7654321;
        LOGMSG(ZONE_INFO, L"Waiting for remote request with ID 0x%08X...\r\n", canFrame.ui32ID);
        dwRet = FlexCANWriteFrame(1, CAN_DATA, CAN_TXONREMOTERX, 0, &canFrame, 10000);
        LOGMSG(ZONE_INFO, L"Frame with ID 0x%08X and data %s sent. Result: %d\r\n", canFrame.ui32ID, DataToHexString(&canFrame), dwRet);

        // Always exit out of loop
        break;
    }

    //Clean up
    FlexCANDeinit(1);

    if (hFinishEvent)
        CloseHandle(hFinishEvent);
    if (hReadThread)
        CloseHandle(hReadThread);

    DeleteCriticalSection(&gCS);

    return 0;
}

The code above is using our standard FlexCAN driver functionality and uses our (free downloadable) debug message templates for debug logging. Our High Performance FlexCAN driver supports complex ID filtering setups and a high speed (virtually unlimited) receive FIFO, among many more features.

Load, unload or reload a driver at runtime

If you develop drivers for Windows CE or Embedded Compact you know it is a major PITA to have to reload the entire kernel every time you change something in the driver code. You need to do this even in a debug kernel because the driver binaries are in use (and thus you can't re-compile & link) when the driver is loaded.

To workaround this I created a tool that allows you to unload or (re)load a driver at runtime. The way I use it is as follows:

  1. I build a small debug kernel including the driver under development
  2. I add the driver dll to the list of modules that will be loaded from the Release Directory (in VS2K5 with PB go to menu "Target"->"Release Directory Modules..." and add the driver)
  3. I add my tool (see below) as a subproject to the OS Design

Now when I download the kernel the driver will load (if the correct Drivers\BuiltIn registry values are there of course). I can set breakpoints in and step through my driver code, etc. Now when I find a bug I just press F5 to continue execution, open a "Target Control" window (menu Target->Target Control) and use my tool to unload the driver, then fix the bug, recompile & link and then (re)load the driver without the need for rebuilding or even reloading the kernel:

reloaddrv [-u] drv1: [[-u] drv2: {etc}]

In Target Control you use the 's' command to start an executable: s reloaddrv -u drv1:

The drv1: is the name of your driver (a 3 letter prefix followed by an index and a colon). Make sure to specify the -u (unload) parameter before the driver name!

To just reload the driver (so a quick unload followed immediately by a load; great for debugging initialization and clean-up) you use the tool as follows: s reloaddrv drv1:

If the driver was not loaded when you executed the above command the tool will try to find the BuiltIn registry key for the driver and load it from there.

You can specify multiple drivers on the commandline as well (-u always applies to the driver directly following it): s reloaddrv -u drv1: -u drv2: drv3: -u drv4: drv5: drv6:

I'm sure this tool is useful to a lot of you developing drivers for Windows CE/Embedded Compact, so here it is:

int WINAPI WinMain(HINSTANCE hInstance,
                   HINSTANCE hPrevInstance,
                   LPWSTR    lpCmdLine,
                   int       nCmdShow)
{
    BOOL bLoad = TRUE;
    LPWSTR pszToken = wcstok(lpCmdLine, L" ");
    while (pszToken)
    {   // Process parameters
        if (wcsicmp(pszToken, L"-u")==0)
        {   // Reset load flag if only unload requested
            bLoad = FALSE;
            pszToken = wcstok(NULL, L" ");
            continue;
        }

        // See if the driver is loaded
        DEVMGR_DEVICE_INFORMATION devInfo = {0};
        LPWSTR pszDeviceKey = NULL;
        devInfo.dwSize = sizeof(devInfo);
        HANDLE hFind = FindFirstDevice(DeviceSearchByLegacyName, pszToken, &devInfo);
        if (INVALID_HANDLE_VALUE != hFind)
        {   // Clean up find handle
            FindClose(hFind);
            // Store driver registry key
            pszDeviceKey = wcsdup(devInfo.szDeviceKey);
            // Unload driver
            RETAILMSG(1, (L"Found driver \"%s\", unloading...", devInfo.szLegacyName));
            DeactivateDevice(devInfo.hDevice);
        }
        else
            RETAILMSG(1, (L"Driver \"%s\" not loaded.", pszToken));

        if (bLoad)
        {   // Load driver if requested
            if (NULL == pszDeviceKey)
            {   // Try to find driver key in registry
                WCHAR szPrefix[4] = {0};
                DWORD dwIndex = 0;
                wcsncpy(szPrefix, pszToken, 3);
                dwIndex = _wtol(&pszToken[3]);
                HKEY hKey;
                BOOL bFound = FALSE;
                if (ERROR_SUCCESS == RegOpenKeyEx(HKEY_LOCAL_MACHINE, L"Drivers\\BuiltIn", 0, NULL, &hKey))
                {   // Opened BuiltIn drivers key
                    DWORD i = 0;
                    WCHAR szDriverKey[MAX_PATH];
                    DWORD dwCount = _countof(szDriverKey);
                    while (ERROR_NO_MORE_ITEMS != RegEnumKeyEx(hKey, i++, szDriverKey, &dwCount, NULL, NULL, NULL, NULL))
                    {   // Enumerate all driver keys
                        HKEY hDriverKey;
                        if (ERROR_SUCCESS == RegOpenKeyEx(hKey, szDriverKey, 0, NULL, &hDriverKey))
                        {   // Check if the prefix matches the specified one
                            WCHAR szDriverPrefix[MAX_PATH] = {0};
                            dwCount = sizeof(szDriverPrefix);
                            RegQueryValueEx(hDriverKey, L"Prefix", NULL, NULL, (LPBYTE)szDriverPrefix, &dwCount);
                            if (0 == wcsicmp(szPrefix, szDriverPrefix))
                            {   // And check if the index matches the specified one
                                DWORD dwDriverIndex = 0;
                                dwCount = sizeof(dwDriverIndex);
                                RegQueryValueEx(hDriverKey, L"Index", NULL, NULL, (LPBYTE)&dwDriverIndex, &dwCount);
                                if (dwDriverIndex == dwIndex)
                                {   // We found our driver key!
                                    bFound = TRUE;
                                    RegCloseKey(hDriverKey);
                                    break;
                                }
                            }
                            RegCloseKey(hDriverKey);
                        }
                        dwCount = _countof(szDriverKey);
                    }
                    if (bFound)
                    {   // Copy driver key name into pszDeviceKey
                        pszDeviceKey = (LPWSTR)malloc(MAX_PATH * sizeof(WCHAR));
                        if (pszDeviceKey)
                            wsprintf(pszDeviceKey, L"Drivers\\BuiltIn\\%s", szDriverKey);
                    }
                    else
                        RETAILMSG(1, (L"Can't find driver key for \"%s\"...", pszToken));
                    RegCloseKey(hKey);
                }
            }
            if (pszDeviceKey)
            {   // Reload driver
                RETAILMSG(1, (L"Reloading from \"%s\"...", pszDeviceKey));
                ActivateDeviceEx(pszDeviceKey, NULL, 0, NULL);
            }
        }
        // Clean up and get ready for next parameter
        if (pszDeviceKey)
            free(pszDeviceKey);
        bLoad = TRUE;
        pszToken = wcstok(NULL, L" ");
    }
    return 0;
}

And for your convenience here's the tool 7-zipped up as an OS Design subproject: reloaddrv.7z

Customizing a UI Component

In this blog post I will show you how you can customize all Windows CE dialogs without the need to change ANY file in the PUBLIC tree. As you no doubt know changing any code in the Windows CE PUBLIC (& PRIVATE) tree is a bad idea. It is a bad idea because it is very hard to maintain, your changes may be overwritten at any time by a Windows CE Update and worst of all your changes affect ALL OS Designs (not just the OS Design you need the changes for). Besides that you often need to do a "Build & Sysgen" to get your changes into your kernel image and we all know you should NEVER EVER do a "Build & Sysgen".

However, MSDN is still full of articles with instructions telling you to change code in the PUBLIC tree. An example of this is the "Customizing a UI Component" article in MSDN. It talks about modifying files in %_WINCEROOT%\Public\Common\Oak\Drivers and changing \WINCE600\PUBLIC\CEBASE\OAK\MISC\Winceos.bat... Bad, bad, bad!

Time for an update on this article:

Customizing a UI Component

To suit the requirements of your target device, Windows CE allows you to customize and replace certain user interface (UI) components. Windows CE provides these UI components in the form of libraries that you can either use as supplied or replace with your own custom UI components. The following table shows these UI components.

Component Description
Oomui Controls the appearance and behavior of your target device in out of memory conditions.
Startui Controls the appearance and behavior of system startup windows.
Calibrui Controls the appearance and behavior of your target device during calibration of the touch screen.

For detailed instructions on how to clone Calibrui please see Cloning CalibrUi in Windows CE 6.0. This article deals with STARTUI and OOMUI

To customize a UI component, we first need to clone the component into our OS Design and change it so that the build system uses our cloned binaries when linking GWES. We'll take STARTUI as an example for this exercise:

  1. Copy \WINCE600\PUBLIC\COMMON\OAK\DRIVERS\STARTUI to \WINCE600\OSDesigns\YourOSDesign\YourOSDesign\STARTUI
  2. Open the 'sources.' file in \WINCE600\OSDesigns\YourOSDesign\YourOSDesign\STARTUI and add the following to the top of the file (right under the !endif):
  3. _OEMINCPATH=$(_WINCEROOT)\public\common\ddk\inc;$(_WINCEROOT)\public\common\oak\inc;$(_WINCEROOT)\public\common\sdk\inc;
    __PROJROOT=$(_PROJECTROOT)
    _COMMONPUBROOT=$(_WINCEROOT)\public\common

    WINCEOEM=1
    PBP_PRESYSGEN=1

  4. Append '_clone' to the TARGETNAME:
  5. TARGETNAME=startui_clone

  6. Add RELEASETYPE and TARGET_PDB_NAME under TARGETTYPE=LIBRARY:
  7. RELEASETYPE=OAK
    TARGET_PDB_NAME=$(_RELEASELIBDIR)\$(TARGETNAME).pdb
  8. Remove the INCLUDES. In this case nothing is included from ..\..\inc but if it would be we would have to include the correct absolute path to the required include files.
  9. Remove any #xref lines (not used anymore since CE 2.12)
  10. The final sources file should look something like this:

    _OEMINCPATH=$(_WINCEROOT)\public\common\ddk\inc;$(_WINCEROOT)\public\common\oak\inc;$(_WINCEROOT)\public\common\sdk\inc;
    __PROJROOT=$(_PROJECTROOT)
    _COMMONPUBROOT=$(_WINCEROOT)\public\common

    WINCEOEM=1
    PBP_PRESYSGEN=1

    TARGETNAME=startui_clone
    TARGETTYPE=LIBRARY
    RELEASETYPE=OAK
    TARGET_PDB_NAME=$(_RELEASELIBDIR)\$(TARGETNAME).pdb

    MODULES=gwes
    CDEFINES= $(CDEFINES) -D__USERDECL_H__ -D__PRIVDECL_H__ -DGWE

    !IFDEF MEM_ACCOUNT
    CDEFINES=$(CDEFINES) -DMEM_ACCOUNT=1
    !ENDIF

    WINCETARGETFILES= \
      $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\$(TARGETNAME).res \
     
    SOURCES=startui.cpp                

  11. Now add this project to your OS Design's subprojects
  12. by right clicking the "SubProjects" node in the Solution Explorer and choosing "Add existing subproject...". Then browse to the STARTUI folder in your OS Design folder and be sure to select "Sources/Dirs Files (sources;dirs)" in the "Files of type" drop down list to be able to select the STARTUI sources. file.

    This action creates several files and adds several lines to our sources file that we do not need...

  13. From the Solution Explorer select all the files in the "Parameter Files" node (ProjSysgen.bat, STARTUI.bib, .dat, .db & .reg) of the STARTUI subproject, right click and "Remove and delete" them.
  14. If you want you can add "startui.rc" and "windowsce.bmp" to the "Resource Files" node in the subproject (but it is not necessary for building).
  15. Now we need to tell Platform Builder that this component needs to built before we sysgen the common tree so GWES can link our binaries instead of the default ones. We do this by editing the STARTUI.pbpxml file. Make sure the STARTUI.pbpxml file is as follows:
    <?xml version="1.0"?>
    <PBProject DisplayName="STARTUI (clone)" SysgenDeptree="common" SysgenModule="gwe2" xmlns="urn:PBProject-schema" />

    I added "(clone)" to the display name just to make clear this is a cloned component; it is not necessary for building. SysgenDeptree tells Platfom Builder this needs to be built before sysgenning the common dependency tree and SysgenModule specifies the module this component needs to be linked with.

  16. Since we named our project STARTUI_clone we need to rename the startui.rc file to startui_clone.rc (in preparation for the step below).
  17. The final step involves building the resources for all possible locales. The script used was taken from the Calibrui clone operation described in Cloning CalibrUi in Windows CE 6.0. The only thing added is setting the INCLUDE environment variable so that windows.h can be found by the resource compiler (startui_clone.rc needs windows.h). Copy the following into the prelink.bat file:
    @echo off
    @REM This is called before build to create all the RES files needed for all locales
    @REM WARNING: Do not change the names of any files because SYSGENMAKE.EXE assumes their location for cloning
    (IF NOT EXIST obj mkdir obj || goto EXIT_ERROR
    (IF NOT EXIST obj\%_TGTCPU% mkdir obj\%_TGTCPU%) || goto EXIT_ERROR
    (IF NOT EXIST obj\%_TGTCPU%\%WINCEDEBUG% mkdir obj\%_TGTCPU%\%WINCEDEBUG%) || goto EXIT_ERROR

    dir /AD /B %_PUBLICROOT%\COMMON\OAK\LIB\%_TGTCPU%\%WINCEDEBUG% > obj\%_TGTCPU%\%WINCEDEBUG%\clone_locales.txt

    set INCLUDE=%_WINCEROOT%\public\common\sdk\inc;
    set _PRELINK_LOCALE=%LOCALE%
    for /f %%L in (obj\%_TGTCPU%\%WINCEDEBUG%\clone_locales.txt) do call :COMPILE_RC %%L
    set LOCALE=%_PRELINK_LOCALE%
    goto :END_CLONING

    :COMPILE_RC
    (set LOCALE=%1 && nmake startui_clone.res) || goto EXIT_ERROR
    (IF NOT EXIST obj\%_TGTCPU%\%WINCEDEBUG%\%1 mkdir obj\%_TGTCPU%\%WINCEDEBUG%\%1) || goto EXIT_ERROR
    move /Y startui_clone.res obj\%_TGTCPU%\%WINCEDEBUG%\%1\startui_clone.res || goto EXIT_ERROR
    goto EOF

    :EXIT_ERROR
    exit /b -1

    :END_CLONING
    @REM Place any additional steps after END_CLONING but before EOF
    :EOF

That's it! You can now modify the STARTUI sources and build (sysgen) your OS Design to see your changes included in GWES, all without modifying one single file in the PUBLIC tree. The same instructions can be used to clone and modify OOMUI (the "out of memory" dialogs).

Good luck!

dwNKWatchDogThreadPriority

Windows CE supports a hardware watchdog implementation. The watchdog's properties can be set through two exported kernel variables; dwOEMWatchDogPeriod (to set the period in ms between feeding the dog) and dwNKWatchDogThreadPriority (to set the priority of the watchdog thread).

Unfortunately, dwNKWatchDogThreadPriority is not defined... Looks like somebody at Microsoft made a typo; the name of the exported variable is dwdwNKWatchDogThreadPriority (note the double 'dw').

Here's some example code to setup the watchdog:

extern DWORD dwOEMWatchDogPeriod;
extern DWORD dwdwNKWatchDogThreadPriority;

dwOEMWatchDogPeriod = 5000;
dwdwNKWatchDogThreadPriority = 100;
pfnOEMRefreshWatchDog = RefreshWatchdogTimer;

void RefreshWatchdogTimer(void)
{
    static BOOL bFirstTime = TRUE;
    OALMSG(OAL_FUNC, (L"+RefreshWatchdogTimer\r\n"));
    if (bFirstTime)
    {
        OALMSG(OAL_FUNC, (L"+RefreshWatchdogTimer: First call; init the Watchdog to timeout reset in %d secs\r\n", WD_RESET_PERIOD/1000));
        WatchdogInit(10000);
        bFirstTime = FALSE;
    }
    else
    {
        OALMSG(OAL_FUNC, (L"+RefreshWatchdogTimer: Subsequent calls; refresh the Watchdog timeout to %d secs again\r\n", WD_RESET_PERIOD/1000));
        WatchdogFeed();
    }
    OALMSG(OAL_FUNC, (L"-RefreshWatchdogTimer\r\n"));
}

Of course WatchdogInit and WatchdogFeed are functions implemented to initialize and feed your hardware watchdog.

Windows Embedded QFE's (updates)

Since the change to Silverlight/Bing on Microsoft downloads, the download search has become completely useless (for fun, try searching for "CE 6.0", then try "CE") [Update: MS seems to have fixed the search phrase problems, so "CE" and "CE 6.0" now return the correct results. Nevertheless; the remainder of this blog post is still valid]. Therefore the links in this post do not work anymore and an update is needed.

All Windows Embedded Compact 7 / Windows Embedded CE 6.0 / Windows Embedded CE 5.0 / Windows CE.NET 4.2 / Windows CE 3.0 (you can leave it to MS marketing to make product naming as confusing as possible...) updates can be found at these links:

Windows Embedded Compact 7
Windows Embedded CE 6.0
Windows Embedded CE 5.0
Windows CE .NET 4.2
Windows CE 3.0

You can still download the QFEInstaller so you don't have to click the QFE installation wizard a million times, but nowadays the msi installers support silent installation through commandline options as well. The QFEInstaller is still handy because it makes sure the QFE's are installed in the right order.

Windows Embedded Compact 7 BSP

Today GuruCE released the first version of the Topaz iMX25 Windows Embedded Compact 7 BSP and image binaries and a new release of the CE 6.0 R3 BSP and image binaries.

Release notes and the latest revision can be downloaded here.

We've also released a new version of the Topaz Flasher.

Speeding up the Windows Embedded Compact 7 build process

When you modify something small in your BSP's code and parameter files (like platform.reg) and want to build it, the right way is to right click your BSP and select "Build and Sysgen" (note that this is NOT the demonic Build and Sysgen variant; this merely results in a cebuild -qbsp).

(for a more in depth discussion of what to build when click here)

The downside of this is that if you happened to have just changed your build configuration from RELEASE to DEBUG (or vice-versa), the build system will rebuild all of the SOC folders in the platform common folder.

The default installation of Windows Embedded Compact 7 comes with 7 SOC folders and rebuilding all of these is completely useless and a waste of time (since your BSP only uses 1 SOC folder, if any at all!).

Luckily, we can let the build system know we only want to build the SOC folders we really need by utilizing "OPTIONAL_DIRS".

Here's how:

  1. Change "DIRS=*" in \WINCE700\PLATFORM\common\src\SOC\dirs. to "OPTIONAL_DIRS=*"
  2. Add "set BUILD_OPTIONS=socdir1 socdir2" to your BSP batch file in \WINCE700\PLATFORM\YourBSP\YourBSP.bat (and set the socdir's to the correct foldernames you want to build separated by a space if you want to build more than 1, eg. "set BUILD_OPTIONS=x86_ms_v1")

That's it! A very quick and easy way to speed up your targeted builds.

PS. This also works for CE 6.0!

How to remove the demonic "Build and Sysgen" commands from Platform Builder for Windows Embedded Compact 7

By now, all of you reading this blog should know that you should NEVER EVER DO A BUILD AND SYSGEN (a "blddemo" without "-q") on your build tree.

The reason for this is that this command will try to rebuild the entire tree which (besides taking forever!) will overwrite binaries that may have been updated through QFE's and will result in errors because Microsoft does not supply all of the source code required to rebuild everything. Executing this command will lead to a corrupted build tree for which the only resolution is to do a complete re-install of Windows Embedded Compact 7. The "(Re)Build and sysgen" commands are only useful for people who have full source code: The Microsoft Windows Embedded Compact Development Team (even with premium shared source you don't get a full 100% of source code!).

This has always been an issue, ever since the invention of Windows CE (now known as Windows Embedded Compact).

Despite years and years of lobbying by many MVPs (including myself) with Microsoft they simply refuse to remove these demonic commands from the build menu. In previous versions of Windows CE it was very simple to remove these commands from the build menu (to prevent accidental clicking of these commands). Unfortunately, things have become worse in Platform Builder for Windows Embedded Compact 7. As in the previous version of Windows CE (6.0 R3) the "(Re)Build and Sysgen" commands are in the "Advanced Build" menu. In the previous version of CE you would simply "Customize" the toolbar and remove the "Build and Sysgen" commands from the "Advanced Build" menu. Not anymore... For some strange reason the "Advanced Build Commands" submenu now shows "(Advanced command placeholder)" when in "Customize-mode" and deleting individual commands is no longer possible:

So, what to do? Deleting the whole "Advanced Build Commands" menu seems a bit rigorous, especially since it does contain some very useful commands (like "Clean sysgen" and "Build Current BSP and Subprojects" etc.). All of these commands are also available by right clicking the correct nodes in the Solution Explorer, but still, it's nice to have them handy in the "Advanced Build Commands" menu as well.

Luckily, Platform Builder for Windows Embedded Compact 7 introduces a new feature; Custom Build Commands.

Using Custom Build Commands we can re-create the non-demonic commands from the "Advance Build Commands" menu and omit the demonic commands. That way we can safely delete the entire "Advanced Build Commands" menu, so let's start with that:

  1. Click "Customize..." in the "Tools" menu
  2. Click the "Build" menu
  3. Right click the "Advanced Build Commands" submenu
  4. Choose "Delete" from the context menu
  5. and finally close the "Customize" dialog

We can now add the useful commands back as custom build commands:

  1. Click "Options..." from the "Tools" menu
  2. Open the node "Platform Builder -> OS Design and Build -> Build Commands"
  3. Click on the "Add" button in the "Custom build commands" section
  4. Add the following commands:
    • Sysgen (blddemo -q)    blddemo -q
    • Clean Sysgen (blddemo clean -q)    blddemo clean -q
    • Build Current BSP and Subprojects (blddemo -qbsp)    blddemo -qbsp
    • Rebuild Current BSP and Subprojects (blddemo -c -qbsp)    blddemo -c -qbsp

Now click OK and see the magic in your "Build" menu:

Hosting webservices on Windows Embedded Compact (Windows CE) using gSOAP

In this blog post I'd like to discuss how to host webservices on a Windows Embedded Compact device. You can certainly consume webservices on a smart device using managed code, but hosting a webservice on the device is unfortunately not possible using managed code. So it's back to good old native code again!

I will use gSOAP, a third party framework, that will do most of the nitty gritty work for us. Sounds easy right? Let's get started!

The most important part is the WSDL (Web Services Description Language) file. The WSDL file is an XML document that describes the interface and thus which methods we want to expose and host on our device. I won't spend much time explaining the WSDL syntax as there are lots of online WSDL tutorials available that explain the syntax much better than I ever could.

For now I just created a very simple WSDL file that describes one very simple webservice method: string HelloWorld(string name)

The wsdl:

<?xml version="1.0" encoding="utf-8"?>
<definitions name="HelloService"
  targetNamespace="http://www.YourServer.com/wsdl/HelloService.wsdl"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:tns="http://www.YourServer.com/wsdl/HelloService.wsdl"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <message name="HelloWorldRequest">
    <part name="name" type="xsd:string"/>
  </message>
  <message name="HelloWorldResponse">
    <part name="answer" type="xsd:string"/>
  </message>

  <portType name="HelloWorld_PortType">
    <operation name="HelloWorldOperation">
      <input message="tns:HelloWorldRequest"/>
      <output message="tns:HelloWorldResponse"/>
    </operation>
  </portType>

  <binding name="HelloWorld_Binding" type="tns:HelloWorld_PortType">
    <soap:binding style="rpc"
      transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="HelloWorldOperation">
      <soap:operation soapAction="HelloWorldAction"/>
      <input>
        <soap:body
          encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
          namespace="urn:examples:helloservice"
          use="encoded"/>
      </input>
      <output>
        <soap:body
          encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
          namespace="urn:examples:helloservice"
          use="encoded"/>
      </output>
    </operation>
  </binding>

  <service name="HelloWorld_Service">
    <documentation>WSDL File for HelloService</documentation>
    <port binding="tns:HelloWorld_Binding" name="HelloWorld_Port">
      <soap:address
        location="http://Topaz:8080"/>
    </port>
  </service>
</definitions>

As you can see there are 6 main tags in the WSDL within the mandatory <definition></definition> tags:

types
Provides data type(s) used for the method parameters and return values.
message
Represents an abstract definition of the data being transmitted. A message consists of logical parts, each of which is associated with a definition within some type system.
portType
A set of abstract operations. Each operation refers to an input message and output messages.
binding
Specifies concrete protocol and data format specifications for the operations and messages defined by a particular portType.
port
Specifies an address for a binding, thus defining a single communication endpoint.
service
Used to aggregate a set of related ports and to set the network location of the actual service.

Basically Type, Message and portType describe the webservice methods used and binding, port and service describe how to transfer the data over the socket.

The location contains the IP address or hostname of the target that runs the server hosting the webservice. In this example I use a Topaz device (you would normally set this to the IP address or hostname assigned to your device).

After this very brief WSDL description let's set up our Visual Studio 2008 project. This will be the biggest task.

Before we can create the actual VS2008 project we need to perform a couple of steps (described in more detail below):

  1. Import the WSDL in an emtpy project
  2. Let gSOAP generate a header file via wsdl2header.exe
  3. Let gSOAP generate the corresponding implementation *.cpp file
  4. Implement our methods

Because gSOAP generates a lot files I prefer to separate the generated files from the actual implementation files so that you only have to focus on your implementation and not what is being generated by gSOAP. So let’s begin and create an empty project in Visual Studio 2008 and add the WSDL file.

Step 1: Import the WSDL in an empty project

Open Visual Studio and create a new C++ smart device project (File menu | New | Project) and enter HelloWorldWebService as the name of the solution.

Select Ok, and click next on the "Welcome to the Win32 Smart Device Project Wizard" dialog. In the "platforms" dialog select the SDK for your target device. As you can see I chose the Topaz device (http://guruce.com/topaz). Select next:

In the "project setttings" dialog select "console application" and "empty project" and click finish.

When the solution is created, go to the solution explorer (normally this would be visible by default but if not: go to View | Solution Explorer) and add a new filter "gsoap" in the "header" section (right click "Header Files", choose Add->New Filter) and do the same in the "source" section. We'll get gSOAP to generate its files there. Now create a new file with extension .wsdl in your solution's folder. Copy the contents of the sample WSDL above and add the WSDL file to your solution (right click on the solution and select “add existing item”). I've named the file HelloWsdl.wsdl. It should look something like this:

Step 2: Let gSOAP generate the header file from our wsdl.

First download gSOAP in order to get the tools needed. You can download gSOAP from this location:
http://sourceforge.net/projects/gsoap2/files/
Make sure you save the extracted files in an appropriate folder for you to remember because we need references to this folder within our visual studio project later on.

Now go back to your solution and right click on the wsdl file and select properties. In the “Custom build step“ add the following command (note that I’ve put the gSOAP tools in the $(SolutionDir); make sure you get the path right and that the solution directory doesn't contain any spaces) in the “Command Line” section:
$(SolutionDir)\gsoap-2.8\gsoap\bin\win32\wsdl2h.exe -s $(InputPath) -o $(ProjectDir)$(InputName).h
This will run the wsdl2h.exe to generate our header file. The parameters specify the input and output file. In the “Outputs” field on the property page enter:
$(InputName).h

.

You need to specify something in the “outputs” field in order to make the wsld ‘compilable’. Note that the path here contains a version number (gsoap-2.8). This can change of course so keep that in mind. Also notice that I did this "setting" for "All Configurations" and not just for the current one.

Click “Apply” and “Ok”, and then right click the wsdl file again and choose “Compile”.
Now our header (HelloWsdl.h) file is generated in the project directory and we need to add this file to the project. In the solution explorer right click on the “gsoap” folder in the header section and choose “add existing item”. Navigate to HelloWsdl.h and add it.

Let’s do the same for generating the cpp file:

Step 2: Let gSOAP generate the cpp source file.

In the solution explorer right click on the HelloWsdl.h, which we just added in the previous step, and select “properties”. In the “Custom build step“ add the following command:
$(SolutionDir)\gsoap-2.8\gsoap\bin\win32\soapcpp2.exe -S $(InputPath)

In the “Outputs” field enter the following:
$(InputName).cpp

.

Right click on the HelloWsdl.h file and choose "compile". This will generate a bunch of files as well, but we are not yet ready to build our solution... If you would try to build the solution at this time, like I did when I first started with gSOAP, you will run into a lot of compile errors so bear with me for a few more steps.

Right click the gSOAP folder in the header section in your solution and add these header files:
- soapH.h
- soapStub.h

Right click the gSOAP folder in the source section in your solution and add these cpp files:
- soapC.cpp
- soapServer.cpp

The next step is to add stdsoap2.h and stdsoap2.cpp to your solution. You can find these 2 files in “gsoap-2.8\gsoap”. Add them together by right clicking the project in the solution explorer and select “Add existing item”. They will automatically appear under the correct “header” and “source” sections.

We’ve added the stdsoap2.h to our solution but we also need to add the directory where stdsoap2.h resides to the project's "include directory list". Add “$(SolutionDir)\gsoap-2.8\gsoap” to the include directorie list by right clicking the project in the solution explorer and click "Properties". In the “Configuration Properties" | C/C++ | General” section you will find “Additional Include Directories”.

Now that we’re done generating files we can actually start to code!

Step 4: Implement our methods

First we need to create the cpp source code containing the main definition and our methods. I will use 2 separate files for this. The first file will contain the server code and will listen to incoming requests/messages. The second file will actually implement our webservice's methods.

Right click on the “Source Files” in the Solution Explorer and select “New Item”. Choose C/C++ file and name the file HelloWsdl.cpp. Do exactly the same for a file called HelloWsdlMethods.cpp.

Your complete solution should now look like this:

.

Let’s start with an easy one; open the HelloWsdlMethods.cpp and copy and paste the following code snippet into that file:

#include "soapH.h"

int ns1__HelloWorldOperation(struct soap*,
                             char*  name,       /// Request parameter
                             char*  &answer     /// Response parameter
)
{
    printf("Hello my method\r\n");

    char* myName = {"Erwin"};
    answer = myName;
    return SOAP_OK;
}

Now if you have built the project prior to adding this piece of incredible intelligent code, you would have seen an unresolved external in the error list: this method. The above function is generated (or better; declared) by gSOAP and the code snippet above is the implementation. You can find the declaration of this method in the generated soapStub.h file:

/************************************************************************\
* Server-Side Operations                                                    
\************************************************************************/

SOAP_FMAC5 int SOAP_FMAC6 ns1__HelloWorld(struct soap*, char *name, char *&answer);

This is where you will find your method's declarations when you have added your own in the WSDL.

We’re almost there! The last thing we need to do is add our server code. Code that will wait for a request from any client. Below is the code needed. It may look complicated at first but don’t let it scare you. This code is taken from the gSOAP website (section 7.2.3 How to Create a Stand-Alone Server in the documentation section: link listed below) with some minor changes that I will describe below:

/** Include the namespaces struct */
#include "HelloWorld_USCOREBinding.nsmap"

int _tmain(int argc, char* argv[])
{
   struct soap soap;
   int m, s; // master and slave sockets
   soap_init(&soap);
   soap_set_namespaces(&soap, namespaces);      //** Set the namespaces **/
   m = soap_bind(&soap, "", 8080, 100);         //** leave the string empty and gSOAP will figure out what our "localhost" is **/
   if (m < 0)
      soap_print_fault(&soap, stderr);
   else
   {
      fprintf(stderr, "Socket connection successful: master socket = %d\n", m);
      for (int i = 1; ; i++)
      {
         s = soap_accept(&soap);
         if (s < 0)
          {
            soap_print_fault(&soap, stderr);
            break;
         }
      fprintf(stderr, "%d: accepted connection from IP=%d.%d.%d.%d socket=%d", i,
            (soap.ip >> 24)&0xFF, (soap.ip >> 16)&0xFF, (soap.ip >> 8)&0xFF, soap.ip&0xFF, s);
      if (soap_serve(&soap) != SOAP_OK) // process RPC request
      soap_print_fault(&soap, stderr); // print error
      fprintf(stderr, "request served\n");
      soap_destroy(&soap);      // clean up class instances
      soap_end(&soap)// clean up everything and close socket
      }
   }
   soap_done(&soap); // close master socket and detach context

   return 0;
}

Copy and paste the code above into HelloWsld.cpp.

I've listed my changes with some comments (/** */). What is added is that we include a namespaces struct to explicitly set the correct namespaces. gSOAP (soapcpp2.exe) will not only generate code files but also a *.nsmap file which generates a static struct containing the correct namespace to use. The soap_set_namespaces() method will set this struct to use it. That’s it!

All of this may seem like a lot of work but when you are finished setting up the project every change you make in your interface (wsdl) will automatically drill down into your implementation. After setting up the project you most likely will only need to work on the wsdl file and HelloWsdlMethods.cpp to add your own methods.

Now that we've created the server on Windows CE it is time to create a client that will consume our service:

The C# Managed Client

Create a C# .NET (desktop) application with just one Form (I'm not going through each single step of how to create a C# .NET application as this is outside of the scope of this article and assumed known). Add just one button to the form and give it a name. After that we need add our webservice reference to the solution (our wsdl file). In the solution explorer right click on "References" and select "Add Service Reference". In the address field enter the path and the name of the wsdl file on your local machine. In my case this is: C:\Data\Development\HelloWorldWebService\HelloWorldWebService\HelloWsdl.wsdl. I named the reference HelloWsdlMethods and this name will appear in the solution explorer. Click "Go":

.

On the main form Double click on the button and paste the following code into the button handler:

private void btnTest_Click(object sender, EventArgs e)
{
    try
    {
        HelloWsdlMethods.HelloWorld_PortTypeClient server = new HelloWsdlMethods.HelloWorld_PortTypeClient();
        string name = server.HelloWorldOperation("Dummy");
        MessageBox.Show(name);
    }
    catch (Exception error)
    {
        MessageBox.Show("Request failed: " + error.Message);
    }
}

The code behind the button will access our server and call the webservices method. As you can see the naming is probably not the best but for this example it will do.
Run the server program (HelloWorldWebService.exe) on the target and run the client on the desktop. If you've done everything correct you should see the following after pressing the "Test" button:
The C# Client running on the desktop:

Application console on the Windows Embedded Compact device:

Things to lookout for

As you have seen there is a bit of work involved to get gSOAP to integrate nicely with Visual Studio 2008. The process is error prone and gSOAP's logging doesn't help much in most cases. In my experience there are basically three areas where things are most likely to go wrong:

  • Location
  • This tag in the wsdl file specifies the network address on which the webservices are running. Make sure it is set right.

  • Namespaces
  • Make sure that the namespaces used in the wsdl file match the ones in the source code (use the nsmap file) and don't forget to call soap_set_namespaces().

  • Hostname
  • Make sure that you leave the hostname empty: soap_bind(&soap, "", 8080, 100). Specifying the hostname does not work on CE. Also the tools wsdl2h.exe and soapcpp2.exe have a lot of options that I did not discuss in this article. However, getting to know the different gSOAP options is definitely worth the time. The gSOAP website contains a wealth of information and the documentation is comprehensive.

Of course this article only shows a very simple example of how to use Webservices on Windows CE with gSOAP but it should be enough to get you going on much more complex webservices hosted on smart devices.

Please let us know if you'd like to see a more complex example (for instance transferring a file through webservices).

Good luck!

Cloning CalibrUi in Windows CE 6.0

If you have a need to clone the calibration application in Windows CE 6.0 you'll run into several problems when following the instructions in MSDN. The instructions on that page seem to be working fine for Windows CE 5.0 but are causing major headaches on Windows CE 6.0...

Time for an update on the documentation to match the correct procedure for Windows CE 6.0:

Cloning the CalibrUi Module

To clone the CalibrUi module

  1. Select the Catalog Items View tab in the workspace window.
  2. Expand the [OS Design Name]\Core OS node, and navigate to CEBASE\Shell and User Interface\Graphics, Windowing and Events.
  3. Right-click Minimal GDI Configuration. In the pop-up menu that appears, select Clone Catalog Item.
  4. The Clone Catalog Item - gwe2 window appears, with a list of component libraries that can be cloned. If the Calibrui module is not already selected, select it and choose OK. In the Cloning Complete window, choose OK.
  5. To make sure that the CalibrUi module has been cloned, select the Solution Explorer tab in the workspace. Expand the Subprojects node. If the cloning operation was successful, you will see CalibrUi (gwe2 clone) in the list of subprojects.
    Note: You must never change the project name CalibrUi (gwe2 clone). Making changes to the project name will affect the build system and cause your run-time image to be built incorrectly or to fail.
  6. Expand the CalibrUi (gwe2 clone) node. All of the source files that relate to the Calibrui module are now available for editing. Any changes to the source files will take effect in any run-time image or executable that you create from this point forward.

You can now try to build the CalibrUi subproject by right clicking it and choosing "Build" from the context menu. If you have sysgenned your OS Design before it should build without any problems.

The problems start when you now (re)sysgen your entire OS Design (needed to include the cloned CalibrUi into your kernel).

When the build system executes sysgen -p dcom preproc a build tool called "SysgenMake.exe" will throw an unhandled exception:

Unhandled Exception: System.ArgumentException: Illegal characters in path.
at System.IO.Path.CheckInvalidPathChars(String path)
at System.IO.Path.GetFileName(String path)
at System.IO.Path.GetFileNameWithoutExtension(String path)
at Microsoft.PlatformBuilder.MainClass.ComputeClonedLibs(String targetLibs, StringDictionary& moduleVars, StringDictionary& environmentVariables, Boolean res2res)
at Microsoft.PlatformBuilder.MainClass.Main(String[] args)
NMAKE : fatal error U1077: 'SysgenMake' : return code '0xe0434f4d'
Stop.

This error is caused by TAB characters in the makefile in \WINCE600\PUBLIC\DCOM\CESYSGEN. Remember that you should NEVER EVER change anything in the PUBLIC or PRIVATE folders? Well, this is an exception. There's simply no way around this bug without changing the TAB characters to spaces, so:

  1. Open \WINCE600\PUBLIC\DCOM\CESYSGEN\makefile. in Visual Studio 2008
  2. Press CTRL-R, CTRL-W (this will turn on "View White Space")
  3. Replace all TAB characters in the file (recognizable by the right arrow character) with spaces
  4. Save the file

If you would now sysgen your OS Design again you will see that it successfully executes the sysgen -p dcom preproc command but unfortunately it will fail a bit later in the build process with the following error:

Copying gwestubs.*
Building combined gwes res file for 0419
SysgenMake -RES2RES %GWES_RESOURCES% -fo C:\WINCE600\OSDesigns\MyOSDesign\MyOSDesign\Wince600\MyBSP_ARMV4I\cesysgen\oak\target\ARMV4I\retail\0419\gwes.res
Res2Res for Windows CE (Release) (Built on Jun 30 2006 16:52:50)
Copyright (C) Microsoft Corp. 1991-2004. All rights reserved.
Res2Res: Ignoring "dummy"
Res2Res: Using C:\WINCE600\public\common\oak\Bin\i386\R2RDUMMY.DLL for temp exe
Res2Res: Using resources from C:\WINCE600\OSDesigns\MyOSDesign\MyOSDesign\calibrui\obj\ARMV4I\retail\0419\calibrui_clone.res.
Res2Res: Adding resources from C:\WINCE600\OSDesigns\MyOSDesign\MyOSDesign\calibrui\obj\ARMV4I\retail\0419\calibrui_clone.res to C:\DOCUME~1\Michel\LOCALS~1\Temp\R2R1A00.tmp.
ERROR: Res2Res: Could not open C:\WINCE600\OSDesigns\MyOSDesign\MyOSDesign\calibrui\obj\ARMV4I\retail\0419\calibrui_clone.res.
Res2Res: Error adding resources (-1) 
 
NMAKE : fatal error U1077: 'SysgenMake' : return code '0x2'
Stop.

It is complaining it can't find the file C:\WINCE600\OSDesigns\MyOSDesign\MyOSDesign\calibrui\obj\ARMV4I\retail\0419\calibrui_clone.res. Let's check if that file exists or not...

This is the tree of the CalibrUi subproject after building it:

+---obj
    +---ARMV4I
        +---retail
            +---0404
            +---0407
            +---0409
            +---040C
            +---0410
            +---0411
            +---0412
            +---0413
            +---0416
            +---041D
            +---0804
            +---0C0A

As you can see all locale subfolders are created *except* 0419 (Russian)... Even though you may not even need Russian this is still causing a problem!

Inside the obj dir of CalibrUi a file named clone_locales.txt is generated. It looks like this file may have something to do with our problem... But who/where/when is this file created?

The magic is in prelink.bat (thank you for the tip MVP Pavel Belevsky!):

@echo off
@REM This is called before build to create all the RES files needed for all locales
@REM WARNING: Do not change the names of any files because SYSGENMAKE.EXE assumes their location for cloning
(IF NOT EXIST obj mkdir obj || goto EXIT_ERROR
(IF NOT EXIST obj\%_TGTCPU% mkdir obj\%_TGTCPU%) || goto EXIT_ERROR
(IF NOT EXIST obj\%_TGTCPU%\%WINCEDEBUG% mkdir obj\%_TGTCPU%\%WINCEDEBUG%) || goto EXIT_ERROR

dir /AD /B %_PROJECTOAKROOT%\files\INTLTRNS > obj\%_TGTCPU%\%WINCEDEBUG%\clone_locales.txt

set _PRELINK_LOCALE=%LOCALE%
for /f %%L in (obj\%_TGTCPU%\%WINCEDEBUG%\clone_locales.txt) do call :COMPILE_RC %%L
set LOCALE=%_PRELINK_LOCALE%
goto :END_CLONING

:COMPILE_RC
(set LOCALE=%1 && nmake CalibrUi_clone.res) || goto EXIT_ERROR
(IF NOT EXIST obj\%_TGTCPU%\%WINCEDEBUG%\%1 mkdir obj\%_TGTCPU%\%WINCEDEBUG%\%1) || goto EXIT_ERROR
move /Y CalibrUi_clone.res obj\%_TGTCPU%\%WINCEDEBUG%\%1\CalibrUi_clone.res || goto EXIT_ERROR
goto EOF

:EXIT_ERROR
exit /b -1

:END_CLONING
@REM Place any additional steps after END_CLONING but before EOF
:EOF

As you can see in the above batch file the folder list in clone_locales.txt is created by the line:

dir /AD /B %_PROJECTOAKROOT%\files\INTLTRNS > obj\%_TGTCPU%\%WINCEDEBUG%\clone_locales.txt

The folder %_PROJECTOAKROOT%\files\INTLTRNS (in our case C:\WINCE600\OSDesigns\MyOSDesign\MyOSDesign\Wince600\MyBSP_ARMV4I\OAK\files\INTLTRNS) apparently does not contain the full list of locales we need for a successful sysgen of the OS Design. We already saw that our %_FLATRELEASEDIR% does seem to contain more locale IDs but at the time of a clean sysgen those folders do not exist in the %_FLATRELEASEDIR% yet, so we need to get them from another location. A bit of searching leads us to \WINCE600\PUBLIC\COMMON\OAK\LIB so lets change the line creating clone_locales.txt to take that location as a source:

dir /AD /B %_PUBLICROOT%\COMMON\OAK\LIB\%_TGTCPU%\%WINCEDEBUG% > obj\%_TGTCPU%\%WINCEDEBUG%\clone_locales.txt

Now if you build the CalibrUi subproject you will end up with this tree:


+---obj
    +---ARMV4I
        +---retail
            +---0404
            +---0407
            +---0409
            +---040C
            +---0410
            +---0411
            +---0412
            +---0413
            +---0416
            +---0419
            +---041D
            +---0804
            +---0C0A

With all the above changes implemented you can finally successfully sysgen your platform with your cloned and modified CalibrUi component!

Syndicate content