Jump to Navigation

Blog

GuruCE releases feature update of their i.MX6 BSP

iMX6
We have finalized testing and have now published official release 1100 of the GuruCE i.MX6 BSP. This release adds a lot of great new features most of our customers will be very happy to see.

Some highlights:

  • Updated Vivante GPU driver to v5.0.11.p8.3
  • Multi-monitor functionality now working properly for all resolutions on i.MX6 Solo and DualLite processors.
  • Boot splash images can now be stored in the system partition (next to the bootloader and kernel images). No need to have a FAT12/16/32 formatted partition anymore.
  • Background color of boot splash screen now determined by color of bottom right pixel of the boot splash image.
  • Updated CEWriter tool to support flashing boot splash images.
  • Added support for external drives (like SATA connected through USB) to CEWriter.
  • Fixed flickering mouse cursor and bad performance when drawing under the mouse cursor.
  • OpenGL XAML render plugin now working properly.
  • Added support for NAND to bootloader and kernel.
  • Added support for external RTCs (Real Time Clock chips). Currently supported (and runtime auto-detected) chips are ISL1208, ISL2020, M41T0, M41T8x and RV4162.
  • Added PCIe core reset code so PCIe driver works on DualPlus/QuadPlus
  • Changed condition for enabling L2 cache double line fill feature to depend on L2C-310 revision. The i.MX6Solo/DualLite and DualPlus/QuadPlus now all have r3p2, so for those processors the double line fill feature is now enabled, resulting in much better cache behaviour (and better realtime performance on those processors).
  • Added bootshell option for directing clocks to CKO1/2 pads
  • Improved clocking code to now properly control reference counts of static divider root clocks
  • Moved clocking code to more logical place in the BSP tree.
  • Further cleaned up and refactor of large parts of the interrupt code.
  • Further clean-up and re-structure of BSP code and tree.
  • And many more improvements, fixes and new features!

Further details in the release notes.

Even though the GuruCE i.MX6 BSP is already the best performing, 100% stable and most feature-rich i.MX6 BSP on the market today, there are always things to improve or fix and new features to implement.

Here's our wishlist:

  • Reduce power consumption and enable super low power modes (DVFS/suspend)
  • Bring hardware accelerated H.264 video codecs to WEC2013 (not just WEC7)
  • Improve Gigabit network performance
  • Animated GIF bootsplash support
  • Create a solid solution for multi-display touch

As always; if you have anything you want us to add to the list or you want us to prioritize an item on the list: contact us and we'll make it happen.

Don't believe the hype? Try it yourself!

We've got free downloadable evaluation kernels for the Element14 RIoTboard, the Boundary Devices SABRE-Lite, Nitrogen6X and Nitrogen6_VM, the Device Solutions Opal6 (DualLite & Quad), the Digi ConnectCore6, the Congatec Conga-QMX6, the NXP SDP (DualLite & Quad) and now also for the Technologic Systems TS-4900 (Solo & Quad) and the Toradex Colibri.

GuruCE website: https://guruce.com
iMX6 landing page: https://guruce.com/imx6
Latest iMX6 BSP release: https://guruce.com/imx6/latest

Adding (all) locales to your Windows Embedded Compact 7 OS

Introduction

This article explains how you can add all of the locales to your OS. You can find a brief description on the National/Regional Language Support (NLS) Catalog Items and Sysgen Variables page.

Although everything in this article relates to Windows Embedded Compact 7 (WEC7), the same is applicable to Windows Embedded Compact 2013 (WEC2013/CE8).

When I was porting a BSP and OSDesign from Windows CE 6.0 to Windows Embedded Compact 7, I ran into some issues regarding localization that I would like to share with you today.

Upgrading your OS from Windows CE 6.0 to Windows Embedded Compact 7

When you are in the process of upgrading or porting Windows CE 6.0 to Windows Embedded Compact 7 or Windows Embedded Compact 2013, you might face some hurdles to get it all working. Once you manage to overcome all hurdles and the operation system is running you're almost done. All you need to do now is adding some missing locales to the OSDesign. That can't be that hard, can it?

Well...

In the good old days of Windows CE 6.0 this was easy. You just had to select the locales you wanted to support in your OS in the properties page of your OSDesign. Simply right click on your OSDesign in the solution explorer, select properties and navigate to the locale tab. That tab page allows you to select the locales you want to support in your OS, then do a rebuild, and that's it.

Windows CE6 Locale Properties

Unfortunately, with Windows CE 7 this is all not so easy anymore. I have no idea why on earth this functionality was 'streamlined', but there are more decisions made around Windows CE that escape any sane reasoning I guess....

To get it all to work in Windows Embedded Compact 7 or 2013 you need to perform some extra steps, and that's exactly what this blogpost will explain. I'll also show you that it is not possible to add ALL, seemingly supported, locales to your OSDesign. To all those people living in Friesland (part of The Netherlands) that speak Frisian or those from Inuktitut (Canada) that use syllabics and some others; sorry, you're out of luck when it comes to Windows Embedded Compact!

In short you need to:

  • Add SYSGEN_NLS_XXX variables to the OSDesign
  • Manually add locales to nlscfg.inf to include all the locales needed for the .NET CF

To show what locales the OS running on your device supports, I created a little test program that enumerates over the available locales and will try to set the culture info and compare information associated with the locale. When you run the application you will see, unless you configured a different default locale, that only one locale "English (United States)" is listed. When you try to use a locale not supported by the OS, for example CultureInfo.CreateCulture("nl"), a PlatformNotSupportedException will be thrown by the managed application. This is reasonable because the locale was not supported in the first place.

The LocaleInfo test program looks like:

List<CultureInfo> missingLocale = new List<CultureInfo>();
List<CultureInfo> supportedLocale = new List<CultureInfo>();
foreach (CultureInfo ci in CultureInfoHelper.GetCultures())
{
    try
    {
        CultureInfo cultureInfo = CultureInfo.CreateSpecificCulture(ci.Name);
        CompareInfo compareInfo = cultureInfo.CompareInfo;
        supportedLocale.Add(ci);
    }
    catch (PlatformNotSupportedException)
    {
        missingLocale.Add(ci);
    }
}

// print out LCID
StringBuilder localeInfo = new StringBuilder();
foreach (CultureInfo locale in missingLocale)
{
    localeInfo.Append(locale.LCID.ToString("X4") + " ");
}

As you can see, the program enumerates the available locales and the Language Identifier (LCID) is stored (and printed), which we will use later. The test application (LocaleInfo.zip) is attached to this blogpost (in full source code). The test application will create a file (locale_info.txt) containing the locale information for the OS it is running on.

Here's what we need to do to add locale support to your OS:

Selecting the right SYSGEN_NLS_XXX variables

The easiest way to add components (sysgen variables) to your OS is to select the sysgen variables in the Catalog: open your OSDesign and locate the catalog window. Navigate to "International" and select the country of the locale you want to add. Let's take Africa as example. Expand "Afrikaans", just like in the screenshot below. Now if you want to add the locale "Afrikaans", make sure you select both variables, otherwise it will not work. So; add SYSGEN_NLS_AF and SYSGEN_NLS_AF_ZA. Note that in order to support one single language you need to select two sysgen variables!

Windows Embedded Compact 7 Locale Sysgen Variables

If you only want to support a few locales than going through the list and manually selecting the locales is not such a big problem. Just make sure that you select both variables per language/locale. Again an example; for the dutch language you'd need both SYSGEN_NLS_NL and SYSGEN_NLS_NL_NL.

In total, there are 197 locales available and if you want to add all those locales you will most likely end up with some form of RSI (Repetitive Strain Injury). To prevent this I created a little batch file that will set all locales that are supported in the catalog. I simply took the list of supported locales from <WINCEROOT>\public\CEBase\oak\misc\winceos.bat. If you're interested in that batch file please contact me and I'll send it to you.

Now that you have selected the locales you want and thus added sysgen variabls, you need to do a rebuild of the OS, so click Rebuild Solution (to understand what to build when read this blogpost).

If you select all available locales, rebuild the entire solution and run the test program again you will see, by examining locale_info.txt, that the application still detects unsupported locales. How is this possible? You've just added them all, didn't you?

Mysteries.. Apparently we need to add the missing locales manually to the OS:

Add locales to nlscfg.inf to support all locales needed for the .NET CF

Apparently adding the sysgen variables is not enough for some locales so we need to do a bit more, but first a little background information:

The .NET Compact framework depends on a 'list' of locales and this list is called the NLS Table. The NLS table describes the locale identifiers (LCIDs) available in your OS. For more information about the NLS Table and the nlscfg.inf, read this page on MSDN: Configuring the NLS Table. In short; the nlscfg.inf contains a list of LCIDs which should be in sync with the locales you enabled via the NLS sysgen variables. You can find the default nlscfg.inf in <WINCEROOT>\public\COMMON\oak\files.

When you run the test application LocaleInfo.exe, it will create a file containing locale information. A snippet from this generated locale_info.txt file:

Locale information current device
Missing locale LCIDs
------------------------------------------------
045E 3801 3C01 1401 0C01 0801 2C01 3401 3001 1001 1801 2001 4001 0401 2801 1C01
2401 047A 044D 082C 042C 046D 0423 0402 0845 0445 0451 047E 141A 0483 0405 0452
0465 0408 540A 0425 0429 0464 0462 083C 0484 0447 0468 040D 0439 101A 041A 042E
040E 042B 0470 0478 045D 0411 0437 043F 046F 0453 044B 0412 0457 0440 046E 0454
0427 0426 0481 042F 044C 0450 0850 047C 044E 043A 0461 046C 0482 0448 0446 0415
048C 0463 0486 046B 086B 0C6B 0417 0418 0419 0487 044F 0485 043B 045B 041B 0424
041C 1C1A 0C1A 301A 281A 181A 081A 2C1A 045A 0449 044A 0428 041E 0442 0432 041F
0444 085F 0480 0422 0420 0843 0443 042A 0488 0434 046A 0804 0C04 1404 1004 0404
0435
------------------------------------------------

The next step is to clone nlscfg.inf located in <WINCEROOT>\public\COMMON\oak\files to <WINCEROOT>\PLATFORM\<YOURBSP>\FILES and then add the list of missing LCIDs listed in locale_info.txt. The contents of the <WINCEROOT>\PLATFORM\<YOURBSP>\FILES folder are copied during the buildrel build phase and after that the makeimg phase will process and include all the locales listed in nlscfg.inf. If you click "Copy files to release directory" followed by a "Make Image", you will see that the makeimg build phase will exit with an error. The makeimg process will fail with error "The cenlscmp tool has exited with error code 1". If you examine the <WINCEROOT>\build.log, it will provide you with some additional information:

CeNlsCmp: Did not find locale 047a in locale file
error MSB3073: The command "cenlscmp <WINCEROOT>\<OSDesign>\..\RelDir\Shipbuild\postproc\nlssrc.txt
<WINCEROOT>\<OSDesign>\..\RelDir\Shipbuild\nlscfg.out
<WINCEROOT>\<OSDesign>\..\RelDir\Shipbuild\wince.nls
<WINCEROOT>\<OSDesign>\..\RelDir\Shipbuild\nlscpg.txt" exited with code 1.

The first line "CeNlsCmp: Did not find locale 047a in locale file" informs you that apparently information is missing for LCID 047a somewhere. I have unfortunately not been able to track down the missing information, so either there is still something missing or there is a bug in the tooling.

I have gone through the process of removing all LCIDs that cause the cenlscmp to break and provide you with a list of all 'supported locales' that can be enabled, just in case you want it 'all'. Attached to this blogpost you'll find the zipped nlscfg.inf file.

In the locale_info.txt (also attached to this blogpost), you'll find a summary of supported and non-supported locales:

Supported Locale

Total locales installed:197
Total locales supported:146
Total locales not supported:51

I hope that this information will save someone somewhere some time! ;-)

QT 5.6.0 official release on the GuruCE iMX6 BSP

Official release Qt 5.6.0 builds and works fine with our GuruCE iMX6 BSP and SDKs!

Download Qt 5.6.0 official source here: https://download.qt.io/official_releases/qt/5.6/5.6.0/single/

We still need to make three patches: download the patches.

The complete guide to building Qt to work with the GuruCE iMX6 BSP and SDK can still be found here: https://guruce.com/blogpost/wec2013-and-qt.

There are no changes in the build steps apart from using the links above for Qt source and the required patches.

GuruCE releases major new version of their iMX6 BSP

iMX6
We have finalized testing and have now published official release 954 of the GuruCE iMX6 BSP. This release adds a couple of great new features many of our customers have been wanting to see supported in our BSP.

Some highlights:

  • Added true multi-monitor support: extended desktop with GDI, OpenGL-ES & OpenVG on all active displays
  • Added support for multi-display boot splash screens, with virtually flicker-free transition to the Windows Embedded Compact desktop
  • Multi-display configuration can be dynamically configured in the bootloader with immediate activation of (and display of bootsplash on) the selected displays
  • Latest Vivante GPU driver (5.0.11.p8.0 + 2G)
  • Introducing CEWriter; a Windows utility that can write a bootsplash, bootloader & kernel image directly to a SATA drive or SD card from your PC
  • Added support for iMX6 Dual+ and Quad+ processors
  • Added support for PCIe enumeration over bridges and switches
  • Added support for Command Line Interface (cmd.exe) over UART
  • Added support for VMINI network adapter while debugging over KITL
  • Added support for very large SATA disks
  • Added support for SD/eMMC 8-bit mode
  • Added support for eMMC 4.4 DDR mode
  • Added support for the Technologic Systems TS-4900 Solo & Quad board
  • Added support for the Device Solutions Opal6 Quad board
  • Added support for the Toradex Colibri DualLite board
  • And many more improvements, fixes and new features!

Further details in the release notes.

Even though the GuruCE iMX6 BSP is already the best performing, stable and feature-rich iMX6 BSP on the market today, there are always things to improve or fix and new features to implement.

Here's our wishlist:

  • Allow storing bootsplash image in system partition (instead of file partition as it is now)
  • Support bootsplash image to be stored in exFAT formatted file partitions
  • Animated GIF bootsplash support
  • Bring hardware accelerated H.264 video codecs to WEC2013 (not just WEC7)
  • Improve Gigabit network performance
  • Create a solid solution for multi-display touch
  • Reduce power consumption and enable super low power modes (DVFS/suspend)

As always; if you have anything you want us to add to the list or you want us to prioritize an item on the list: contact us and we'll make it happen.

In case you did not see it yet, the video below highlights some of the features of our previous BSP release. We'll create a new video highlighting the new release features (like bootsplash and multi-monitor) soon.

Don't believe the hype? Try it yourself!

We've got free downloadable evaluation kernels for the Element14 RIoTboard, the Boundary Devices SABRE-Lite, Nitrogen6X and Nitrogen6_VM, the Device Solutions Opal6, the Digi ConnectCore6, the Congatec Conga-QMX6, the Freescale/NXP SDP and now also for the Technologic Systems TS-4900 and the Toradex Colibri.

GuruCE website: https://guruce.com
iMX6 landing page: https://guruce.com/imx6
Latest iMX6 BSP release: https://guruce.com/imx6/latest

Meet us at the NXP FTF 2016 TECHNOLOGY FORUM from 16 to 19 May 2016, in Austin, Texas.

QT 5.6.0 Beta release is out!

Recently QT 5.6.0 Beta has been released. You can download the QT5.6.0 beta package from the QT download page.

So for anyone who followed the tutorial how to build QT for WEC2013 with the GuruCE iMX6 SDK, a new patch is available for download.

There are no changes in the build steps you only need to use the beta patch to run!

WEC2013 and Qt

Introduction

On a regular basis we receive requests whether it is possible to run Qt applications on platforms running our iMX6 BSP. To be able to run Qt applications you need a "Qt Application SDK" which is build against our GuruCE iMX6 SDK. This article will show you how to build the Qt Application SDK so you can run Qt applications on a device running the GuruCE iMX6 BSP.

This step described in this text apply to the QT5.6 alpha release which (sort of) includes WEC2013 support in combination with Visual Studio 2013. The WEC2013 support in this version of Qt is not completely working yet so you'll need to perform some additional steps to make it all work.

We'll show you exactly what you need to do, and while we're at it we'll add support for Visual Studio 2015 as well!

This article seems quite big but actually it isn't all that hard. For the impatient; you'll find a quick reference guide of all the steps to follow at the end of this article.

Qt 5.6 Alpha Release

The instructions in this article apply to the Qt 5.6 alpha release. As soon as we have tested the official 5.6 release, and perhaps other future releases, we'll update this article so it all works with the latest Qt release.

Qt is an open-source project and the git repositories allow you to get the latest and, sometimes not so, greatest developer branches. You can find instructions for getting the complete source code tree from the git repository here. Qt is a very active project, which is good in a way, but it also means there are a lot of commits every day. This can easily result in a broken build, especially since not every commit is checked against all the different platforms and build environments (which make sense in a way). Our suggested approach is to pick the latest stable release and make that work. Of course you can take the latest alpha, beta or even developer branch but in that case you may want to prepare yourself for some long days/nights chasing build errors! ;-)

[Update 21/12/2015]
QT 5.6.0 Beta is released. You can find the patch needed in order to build QT5.6.0 beta here. There are no other changes required in order to build QT for WEC2013 just as described in this article, except that you need to run the beta patch.

Qt Prerequisites

You'll need to download and install a couple tools and packages before you can start building the Qt application SDK:

  • Download and install Python. Make sure the Python binary folder is added to the system's %PATH% variable. This will be requested during installation.
  • Download and install Perl. Also the Perl binaries must be accessible by the build system, and so the binary folder also needs to be added to the %PATH% system variable.
  • Install Visual Studio 2013 or Visual Studio 2015.
  • Install Application builder for Embedded Compact 2013".
  • Download and install the latest GuruCE iMX6 SDK. You can pick any preferred platform. For Visual Studio 2015 you'll need the SDK of a release later than r550 (coming soon).
  • Download the Qt 5.6 alpha release from this location. Extract the source to any folder but make sure the extracted source code is on the same drive as the "working directory" (the directory where your generated binaries will end up).

The Qt 5.6 alpha source path used in this article is: H:\qt-everywhere-opensource-src-5.6.0-alpha
The Qt working directory used in this article is: H:\Qt\QT5.6a

Patch the Qt sources

The current 5.6 alpha release won't build for Windows Embedded Compact without some changes to the Qt source tree. We have packaged up all required patches and made them available for download here). All these patches are made by us and may not conform to the Qt coding standards, so please monitor the bug tracker for Qt to see if better solutions become available.

One of the patches also results in some mkspec files to be copied into the "Qt source tree\qtbase\mkspec" folder. These mkspec's contain the configuration information for the development environment and target platform. In our case we need mkspec files to indicate we use Visual Studio 2013 or Visual Studio 2015, the GuruCE iMX6 SDK and a Windows Development machine.

All said and done, lets build a Qt Application SDK now!

Building the Qt Application SDK

1. Install the patches

Download the Qt56alpha_patches.zip file and extract it in the root of the QT5.6a source path. You should end up with a "patch" folder after extraction (e.g. H:\qt-everywhere-opensource-src-5.6.0-alpha\patch). Navigate to this patch folder and run the patch.bat batch file.

If you want to undo the patches just open a Command Prompt in the patch folder and run:

H:\qt-everywhere-opensource-src-5.6.0-alpha\patch>patch -u

This will revert the changes made by our patches and restore the original Qt code tree.

2. Open Visual Studio 2013 or Visual Studio 2015 Developer Command Prompt

With Visual Studio 2013 there is no 'standard' start menu item for opening the Visual Studio 2013 "Developer command prompt", but shortcuts are available. Open a file explorer and navigate to the Shortcuts folder inside your Visual Studio installation folder, eg:

"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts"

Run the shortcut: "Developer Command Prompt for VS2013"

For Visual Studio 2015 there is a start menu item for the Developer Command prompt, just type "Command" in the desktop search pane and it should show up:

In both cases (VS2013 or VS2015) you can drag the developer command prompt shortcut to the desktop. This allows you to quickly open a developer command prompt whenever needed.

3. Set %PATH% variable to the source path

In the Visual Studio 2013/2015 developers command prompt, navigate to your Qt working directory (e.g. H:\Qt\QT5.6a). Remember that QT5.6a source path and the work directory must be on the same drive. Add the QT5.6a source path to the %PATH% environment variable by executing the following command (of course change the drive and folder name if needed):

set PATH=%PATH%;H:\qt-everywhere-opensource-src-5.6.0-alpha

You can also add this variable to the system environment variables. In that case you must not forget to change it in case you change the Qt working folder (for instance when you want to build a Qt Application SDK against a different Qt source tree). Setting the Qt source path in the command prompt is the most flexible way and allows you to build a Qt SDK against different Qt source trees.

4. Configure the Qt build environment

Execute the following command in the Visual Studio 2013 Developer command prompt (followed by enter):

H:\Qt\QT5.6a>configure -platform win32-msvc2013 -xplatform wince80GuruCE-armv7-msvc2013 -rtti -mp -ltcg -release -opensource -confirm-license -no-compile-examples -nomake tests -opengl es2 -openvg -skip qtandroidextras -skip qtactiveqt -skip qtsensors -prefix %CD%\SDK

Or for Visual Studio 2015 execute the following:

H:\Qt\QT5.6a>configure -platform win32-msvc2015 -xplatform wince80GuruCE-armv7-msvc2015 -rtti -mp -ltcg -release -opensource -confirm-license -no-compile-examples -nomake tests -opengl es2 -openvg -skip qtandroidextras -skip qtactiveqt -skip qtsensors -prefix %CD%\SDK

Now relax, take a deep breath and we'll go over the parameters while configure.bat runs (shouldn't take more than a minute or so).

The configure tool will generate the configuration and build tools needed to build Qt for the given platform and environment. Check the Qt documentation for detailed information regarding the configure tool.

    -plaform win32-msvc2013 -or- win32-msvc2015: Specifies Windows Desktop and Visual Studio version.
    -xplatform The target platform: the GuruCE iMX6 SDK.
    -rtti Compile run-time type information.
    -mp Enable multi-processors when building the SDK.
    -ltcg Use link-time code generation.
    -release Build a release configuration for the SDK.
    -opensource Compile and link the open source edition of Qt Check Qt licensing for more info.
    -confirm-license By specifying this parameter you automatically accept the selected Qt license (in our case this is the open-source license).
    -nomake Exclude a specific part from the build. In our case we skip building the tests. In case you want to save some disk space you can specify -nomake examples. This will leave out the Qt examples. In our case we want to use the examples later on so don't specify -nomake examples.
    -no-compile-examples Indicates not to compile the examples but include them as source in the SDK.
    -opengl The GuruCE iMX6 BSP fully supports hardware accelerated OpenGL ES2.0, so enable es20 in Qt.
    -openvg The GuruCE iMX6 BSP fully supports hardware accelerated OpenVG, so enable OpenVG in Qt.
    -skip This will exclude complete modules from the build. In our case we skip the qtandroidextras, qtactiveqt and qtsensors modules.
    -prefix This indicates the path of where to install the SDK locally. If you don't specify the -prefix parameter, everything will be installed in the working directory.

When configure.bat is finished you can review the used configuration settings by checking the "config.summary" file, which is located in the generated qtbase folder (in our case H:\Qt\QT5.6a\qtbase).

5. Build the Qt Application SDK; time for coffee!

To start the build process the only thing left to do is to enter the following command in the Visual Studio 2013/2015 Developer command prompt:

H:\Qt\QT5.6a>nmake

This process will take roughly an hour depending on your development machine configuration.

Install the SDK

When the build is done we can generate the Qt Application SDK installer. Type the following command followed by enter:

H:\Qt\QT5.6a>nmake install

This will generate the folder specified by the -prefix in the configure command line, in our case H:\Qt\QT5.6a\SDK.

The last thing we need to do is copy a qt.conf file into the SDK's bin folder. qt.conf is used to override hard-coded paths defined in the Qt libraries. The qt.conf file specifies where a Qt application can find libraries to link against. Every application needs a seperate qt.conf file if it's not present in the SDK\bin folder.

The contents of the qt.conf are quite simple:

[Paths]
Prefix=..

Download and extract the qt.conf.zip file and copy the qt.conf file to the generated SDK\bin folder (e.g. H:\Qt\QT5.6a\SDK\bin).

That's it! Now you can copy the SDK folder to the device. The size of the Qt Application SDK is approximately 420MB so this Qt Application SDK can be easily shared among developers.

Test Qt

When the Qt Application SDK is built, installed and it contains the qt.conf file in the SDK\bin directory, we can copy the Qt Application SDK to the device and run a Qt application:

  • Copy the SDK folder to the Windows Embedded Compact device.
    You can copy the SDK folder to the root of an SD card and insert the SD card into the device running CE. The Qt Application SDK folder contains an "examples" folder with sample applications you can try. To run the sample applications continue the steps below.
  • Telnet to the device.
  • Navigate to the Qt Application SDK bin folder: cd \SD\SDK\bin.
  • Start qml.exe with the following parameters, followed by ENTER:

\SD\SDK\bin>qml ..\examples\quick\animation\animation.qml

Telnet Screenshot

  • Choose any of the samples, for example "ColorAnimation":

    Running Qt Animation Application

    Is it really all that great?

    This article describes how to build the Qt Application SDK and how you can run a simple Qt application. We have not tested the Qt Application SDK more than what we described in this article. Testing all features of Qt is certainly possible, but our time is better spend adding low-level functionailty to our iMX6 BSP. We are certain there are more problems in the Qt source code than what we discovered so far; Windows Embedded Compact specific, but most probably also generic issues. Hopefully the final release of Qt 5.6 will solve a lot of the issues we have discovered. It's always good to participate and report issues to the Qt community, like we did as well. Current known issues we see in Qt 5.6 alpha are for instance:

  • qmlscene.exe sample application crashes. [update 18-12-2015] This is fixed now in the new patch
  • Visual Studio plugin is not accepting the Qt Application SDK build.
  • And probably some more...
  • Quick reference guide

    This is a summary of all the steps required to build the Qt Application SDK for the GuruCE iMX6 SDK:

    The Qt 5.6 alpha source tree location: H:\qt-everywhere-opensource-src-5.6.0-alpha
    The Qt working directory: H:\Qt\QT5.6a

    Nr. Description Command
    1 Make sure you meet the prerequisites and QT5.6a code tree is extracted (e.g. H:\qt-everywhere-opensource-src-5.6.0-alpha) -
    2 Download and extract the Qt56alpha_patches.zip file in the root of the QT5.6a source tree -
    3 Open a command prompt in the root of the Qt source code tree and run the patches: \H:\qt-everywhere-opensource-src-5.6.0-alpha\patch\patch.bat
    4 Exit command prompt exit
    5 Open VS2013 or VS2015 Developer command prompt and navigate to the work directory cd H:\Qt\QT5.6a
    6 Run the Qt configure tool for Visual Studio 2013 configure -platform win32-msvc2013 -xplatform wince80GuruCE-armv7-msvc2013 -rtti -mp -ltcg -release -opensource -confirm-license -no-compile-examples -nomake tests -opengl es2 -openvg -skip qtandroidextras -skip qtactiveqt -skip qtsensors -prefix %CD%\SDK
    - or -
    6 Run the Qt configure tool for Visual Studio 2015 configure -platform win32-msvc2015 -xplatform wince80GuruCE-armv7-msvc2015 -rtti -mp -ltcg -release -opensource -confirm-license -no-compile-examples -nomake tests -opengl es2 -openvg -skip qtandroidextras -skip qtactiveqt -skip qtsensors -prefix %CD%\SDK
    7 Build the SDK nmake
    8 Install the SDK nmake install
    9 Download and extract the qt.conf.zip file. Copy qt.conf to SDK\bin -
    10 Copy/FTP the Qt Application SDK to the device (~420MB) -
    11 Telnet to the device telnet 192.168.2.15
    12 Navigate to SDK location cd \sd\SDK\bin
    13 Run the animation sample qml ..\examples\quick\animation\animation.qml

    New GuruCE iMX6 BSP release 550 adds support for Freescale SABRE Smart Device Platform (SDP)

    GuruCE Logo

    To celebrate GuruCE becoming an official Freescale Proven Partner we added support for the Freescale SABRE Platform for Smart Devices Reference Design (DualLite & Quad) to our iMX6 BSP.

    Free downloadable WEC7 and WEC2013 evaluation kernels for the Freescale SDP-DL and SDP-Q, as well as a myriad of other supported boards can be found here.

    Some highlights of release 550:

    • Support for the Freescale SDP-DL and SDP-Q
    • Support for the new Boundary Devices Nitrogen6_VM
    • Further cache optimizations to improve real-time performance
    • Full support for Qt 5.5 on WEC7 and WEC2013
    • Better RS485 support
    • Added temperature monitor driver
    • Improved performance of FTP server code
    • Many more improvements, see the Release Notes for all the details

    Download our demo kernel images now and see for yourself why no other iMX6 BSP on the market today can compete with the quality, performance and stability of the GuruCE iMX6 BSP!

    It’s Time For Windows 10 IoT

    This is a guest blog post by Ken Marlin

    Windows 10 is coming! Quickly in fact. It’ll be here July 29th, 2015 and that leaves very little time to get ready. You may have seen an article or two on the 6 versions of Windows 10 but I’m going to cover all 10 editions. In the past 8 months, I’ve attended a ton trainings on Windows 10 and visited the Redmond Campus 6 times. Microsoft has been upfront about Windows 10 and they have provided information on a monthly basis, but the time has come – it’s here and it “IS” the O/S you will want moving forward!


    10 VERSIONS OF WINDOWS 10

    The news recently covered 6 or 7 versions of Windows 10 but most articles were leaving out the embedded (now called IoT) family of products. If you include the OEM Embedded versions, you jump to the wonderful count of 10 different flavors of Windows 10. See the Full list below.

    Windows 10 Home – Non Domain for Home Users focused on Consumers

    Windows 10 Pro – Domain connected for Business and Expert users.

    Windows 10 Enterprise – A Volume upgraded edition that adds Corporate Security and other Features

    Windows 10 Education – A Volume edition via Academic licensing for Schools/Faculty/Students

    Windows 10 Mobile – Avail Direct Only for Smartphones and Small Tablets (Win Phone Replacement)

    Windows 10 Mobile Enterprise – Volume Upgrade adds Enterprise Security/Features to Mobile Devices

    Note Microsoft has renamed “Embedded” to “IoT” for Internet Of Things. Here are the new Embedded flavors of Windows now named using the “IoT” tag.

    Windows 10 IoT Enterprise – Embedded Industry Edition with Embedded Lockdown Features

    Windows 10 IoT Mobile – Embedded Direct Only option for Smartphones/Small Tablets

    Windows 10 IoT Core – Free of Charge for small x86 and ARM devices – no Shell provided.

    .Net Micro Framework – Free and Open Source with support for very low-end ARM devices.


    THE PRICE

    Free! Well not for every version and for a limited time but let me explain: Consumer and OEM System Builder versions will be a free “Upgrade” from Windows 7 and Windows 8.1 editions where you have a legal license.

    What about the Embedded (IoT) family of Windows 7 and Windows 8.1 products – do they qualify for the upgrade? It depends. The FES family known as the For Embedded Systems products because they are 100% bit for bit identical to the full Windows products, will be eligible for the free upgrade. As long as those FES devices are connected to the internet and have Windows Updates enabled, they will get the free upgrade notification allowing them to be upgraded for free to Windows 10 Pro. However the WES and POS/Industry family would not qualify for this limited time free upgrade.

    What about the Enterprise Volume license space for Win7 and Win 8.1? At this time the answer is no. Many customers who use the Enterprise Volume license typically have Software Assurance and if you have activate SA then you would in fact be getting the rights to Windows 10 Enterprise but only if your SA is active.


    ELEVATOR PITCH – What’s it get me if I upgrade?

    Most importantly it gets you a familiar user experience that your users will already be comfortable in using. Secondly it gets you the ability to run not only all your Win32/Win7/Win8 applications but it also adds a new Universal Application platform that allows the Apps written to work on all Windows 10 devices across device sizes including Xbox One, Windows Phone, Tablets, Desktops and even the new Surface Hub – 80” Display. It has improved security with the new “Hello” biometrics and face recognition capability as well as new DirectX12 graphic performance enhancements. They’ve also added a new Modern Browser called “Edge” that will compete with top Browsers on the market while keeping the IE11 version for backwards compatibility. Lastly, for a period of one year the product is free for consumer home use so I suggest you download it today or reserve you free copy via Windows Update.


    EMBEDDED IoT OEM’s – What’s in it for me?

    To start with a very simplified roadmap and a product family that has a unified toolset which gets you the ability to write applications once then run them across the entire Windows 10 family of devices. If you are building a small x86 or Arm device with low specifications you can use the Windows 10 IoT for Core devices which is now a free license. If you are building a device that requires more horsepower and would already have the Windows shell then you have the simplified choice of Windows 10 IoT for Enterprise/Industry devices. One part number and family to work with and one toolkit to work with.


    HOW TO GET IT TODAY

    Signup for the Tech Preview and look within your MSDN Subscription as the latest build is available via the MSDN download site. Lastly, watch for the Windows 10 reserve your copy balloon notification if you have a Windows 7 Pro/Ult or Windows 8.1 Pro system with the latest updates. It arrives July 29th. Get the Preview today from here: http://windows.microsoft.com/en-us/windows/preview-iso


    THE EMBEDDED IOT CONCERN

    If you built your OEM appliance using the For Embedded System versions of Windows 7 Pro/Ult or Windows 8.1 Pro and the device is connected to the internet with updates enabled you need to beware that the Windows 10 Free upgrade notifications have officially started. It means your device could very well be displaying a notification to users to reserve the Windows 10 upgrade which will go live July 29th. Most OEMs probably do not want this notification to be displayed on their appliance nor would they want the end-user to upgrade the device to Windows 10 because the application would not have been tested on Windows 10 and could break the appliance.

    The latest information provided to our Embedded OEMs help set a registry key that will block any O/S upgrades. You can use group policy (which sets a registry key) or you can use the key directly. The group policy already exists on any PC which installed these KBs: Windows 7 SP1 – KB3050265 or Windows 8.1 Update – KB3050267.

    Customers or OEMs should look for the Group Policy at this path:

    Computer Configuration / Administrative Templates / Windows Components / Windows Update

    It is called “Turn off the upgrade” to the latest version of Windows through Windows Update. If the group policy is set, then an OS Upgrade will never be detected, downloaded, or installed on that PC. The OS Upgrade applicability will look at the Policy registry key that’s set when you enable that policy:

    HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

    DWORD: DisableOSUpgrade == 1 when that policy is set

    These two KB articles will be updated with the following note:

    https://support.microsoft.com/en-us/kb/3050265

    https://support.microsoft.com/en-us/kb/3050267

    IMPORTANT:

    This update also installs a new group policy that allows you to block upgrades to the latest version of Windows through Windows Update. Computers with this policy applied will never detect, download or install an upgrade to the latest version of Windows.

    Policy Path: Computer Configuration / Administrative Templates / Windows Components / Windows Update

    Policy setting: Turn off the upgrade to the latest version of Windows through Windows Update (enabled, disabled)


    IOT ACTIVATION

    Embedded OEMs love WES7 because it had by-pass activation built into the product. If you have a device that you did not want to connect to the internet then WES7 was a great choice. Flash forward to Windows 10 and now with the Windows 10 IoT Enterprise edition you will receive a single PID/Key and your device will run without any activation notifications as long as it is not connected to the internet. If you do connect it to the internet then it will attempt to activate and will do so in the background without Windows 10 IoTany notifications. It’s a quiet type method of activation.


    SINGLE TOOLKIT FOR ALL EDITIONS – WICD

    Windows Image Configuration Designer – pronounced “Wicked” is the new tool that has been heavily simplified and covers all editions. Download it today and start practicing with the new tool.

    I’ll close by suggesting again that you go download the latest Tech Preview and start testing. I’ve been running the Tech Preview since last November and it is proving to be the edition where Microsoft listened to the users and developers. It’s the edition to move your projects toward.


    NINJA CAT

    The Ninja Cat meme has been embraced by Windows Insiders everywhere as well as Microsoft. To learn more and download a copy of a Ninja Cat image for your device check out this article.



    About the Author
    Based in Phoenix, Ariz., Ken Marlin is a Microsoft MVP and Microsoft Champion at Avnet Embedded. He has over 25 years of Microsoft experience supporting all Microsoft products and programs with specialties in Microsoft OEM Embedded appliances as well as OEM System Builder and Volume programs. Ken is very passionate about technology in general and is also a Game Master for the annual Avnet Tech Games Competition. He is a first time contributor to the GuruCE blog. More about Ken here.

    GuruCE and Boundary Devices announce official partnership

    Boundary Devices LogoGuruCE Logo


    PRESS RELEASE:
    Chandler AZ, USA, and Ohiwa, New Zealand, 27 July 2015

    Boundary Devices, a leading global supplier of ARM-based single board computers and System-on-Modules for the general embedded market, and GuruCE, well-known manufacturer of high quality Microsoft Windows Embedded Compact BSPs, today announced their official partnership.

    GuruCE fully supports Boundary Devices' iMX6 based single board computers and SOMs in their very popular iMX6 BSP for Windows Embedded Compact 7 and 2013.

    “GuruCE has put together an impressive CE7 and CE2013 BSP for i.MX6. The performance enhancements, features, and stability are ideal for embedded customers who are looking to use Windows Embedded Compact in their product. The GuruCE team has demonstrated a high-level of expertise with Windows Embedded Compact and is a great software partner that we highly recommend”

    Pejman Kalkhoran, Partner at Boundary Devices.

    “Boundary Devices popular and high quality SBCs and SOMs are a valuable addition to our GuruCE iMX6 BSP range of supported boards”

    Michel Verhagen, CEO of GuruCE.

    About GuruCE
    GuruCE offers deep technical knowledge of Windows Embedded Operating Systems. The consultants of GuruCE are among the best in Windows Embedded BSP & driver development, training and consulting. They help customers overcome the steep learning curve and greatly reduce the time-to-market for their products. GuruCE operates as an umbrella for the top 5% of talented Windows Embedded consultants and employs local experts in Europe (Netherlands), USA and New Zealand. For more information please visit https://guruce.com

    About Boundary Devices
    Boundary Devices is a leading global supplier of ARM-based single board computers and System-on-Modules for the general embedded market. Founded in 2003 and headquartered in Chandler, AZ, Boundary Devices is a Freescale Proven Partner and have completed numerous successful projects with the I.MX family of processors. All boards are manufactured in the USA by specialists service providers in accordance with modern quality standards. All hardware is designed and tested in our Chandler, AZ facility. Software is always a barrier in embedded designs. With a significant amount of software partners as well as high-level internal expertise, Boundary Devices is well-positioned to provide the right software solution for your embedded design. For more information visit http://boundarydevices.com/

    Old rev 1.0 iMX6 CPUs not supported

    We've received reports of problems with our demo kernels on boards with a rev 1.0 iMX6 CPU. If you encounter problems, please first check the CPU revision of the iMX6 on your board.

    You can do this by breaking into the bootloader menu, type 'B' to get to the bootloader shell, then type 'i' followed by ENTER and check the number after 'Revision'. If this number is smaller than 1.1 you will not be able to successfully run our demo kernels on your board. Press 'x' or 'q' followed by ENTER to exit the bootloader shell.

    The reason we do not support revision 1.0 iMX6 CPUs is simply because we do not have any board with a rev 1.0 CPU on-board, and thus have not been able to test our BSP with rev 1.0 CPUs. If you have an old board and want us to add support for rev 1.0 CPUs, please contact us.

    ------------------
    System Information
    ------------------
    Processor                          = iMX6 Quad (4 cores)
    Speed grade                        = 996 MHz
    Temperature grade                  = Automotive -40 to 125C
    Revision                           = 1.2
    Silicon revision                   = 1.0
    SOC version                        = 1.0
    Fuse MAC                           = 00:00:00:00:00:00
    USB VID/PID                        = 0000/0000
    GP1                                = 0x00000000
    GP2                                = 0x00000000
    64 bit UID                         = XXXXXXXXXXXXXXXXX
    256 bit SRK                        = 0000000000000000000000000000000000000000000000000000000000000000
    SRC Reset Status Register          = 0x00000001

    GuruCE iMX6 BSP video

    We've just uploaded a little video showcasing our latest BSP release, have a look:

    Major new release of the GuruCE iMX6 BSP!

    iMX6
    We have just released the latest version of our iMX6 BSP!

    We made some major improvements in performance and have added quite a lot of functionality.

    The highlights:

    • 4.75x faster than our previous release
    • This is >6x (!) faster than our competitor's BSP...

    • Added full HDMI support, including display auto-detection, hot-plug and dynamic resolution changes in CE
    • This means you can plug in a 1360x768 monitor and have the CE desktop shown in that resolution, then unplug the monitor and plug in a 1920x1080 monitor and CE will dynamically change resolution and show the desktop in 1920x1080 resolution, all this of course without the purple line on the left (a long standing problem in all the other iMX6 BSPs available).

    • HDMI, LVDS and LCD display output is now configurable in the bootloader
    • This means we have one kernel image for all. Just go into the bootloader menu and select which display you are using at which resolution and launch the kernel. Simple as that!

    • Added support for DMA on all UARTs
    • Full RX & TX DMA support on UART1, 2, 3, 4 and 5.

    • Upgraded to the latest Vivante GPU GALCORE driver v5.0.11 (25762)
    • And we added all the tutorials and test code as well. Together with the amazing performance increase of this release you can now enjoy 110+ fps in full screen 1920x1080 (and 350+ fps windowed) for OpenGL-ES 1.1/2.0! The OpenVG spinning tiger sample is now so fast you only see a blur, and we fully support OpenCL on Dual and Quad of course.

    • Now asynchronously loading drivers for faster boot
    • Added free downloadable demo kernel for Congatec-QMX6 (Dual/Quad, 1 GB module) on a QKIT-ARM
    • Maximum CPU temperature at rest: 45°C / 113°F
    • Maximum CPU temperature while running OpenGL-ES 2.0 reflecting ball: 65°C / 149°F
    • This is not nearly as low as we would like, but it's a lot better already. Our next release will focus on power-consumption and heat generation reductions.

    • Improved network performance
    • The performance improvements also make Ethernet throughput a lot better. We're only halfway to reaching the theoretical maximum possible on the iMX6 of ~45 MByte/s (it's on our list of things to fix), but at least Ethernet speeds are out of the KByte range now (tested using NETIO on WEC7 & WEC2013):

      NETIO - Network Throughput Benchmark, Version 1.32
      (C) 1997-2012 Kai Uwe Rommel

      TCP connection established.
      Packet size 1k bytes: 19.11 MByte/s Tx, 19.22 MByte/s Rx.
      Packet size 2k bytes: 21.22 MByte/s Tx, 20.38 MByte/s Rx.
      Packet size 4k bytes: 22.44 MByte/s Tx, 20.85 MByte/s Rx.
      Packet size 8k bytes: 23.06 MByte/s Tx, 22.43 MByte/s Rx.
      Packet size 16k bytes: 20.67 MByte/s Tx, 19.38 MByte/s Rx.
      Packet size 32k bytes: 20.79 MByte/s Tx, 20.58 MByte/s Rx.
      Done.

      UDP connection established.
      Packet size 1k bytes: 13.84 MByte/s (0%) Tx, 13.76 MByte/s (0%) Rx.
      Packet size 2k bytes: 15.97 MByte/s (0%) Tx, 15.97 MByte/s (0%) Rx.
      Packet size 4k bytes: 20.25 MByte/s (0%) Tx, 19.83 MByte/s (0%) Rx.
      Packet size 8k bytes: 22.39 MByte/s (0%) Tx, 22.49 MByte/s (0%) Rx.
      Packet size 16k bytes: 19.34 MByte/s (0%) Tx, 17.95 MByte/s (0%) Rx.
      Packet size 32k bytes: 21.78 MByte/s (0%) Tx, 21.17 MByte/s (0%) Rx.
      Done.

    Full details in the release notes.

    Don't believe the hype? Try it yourself!

    We've got free downloadable demo kernels for the RIoTboard, the SABRE-Lite, the Nitrogen6X, the Opal6, the ConnectCore6 and now also the Conga-QMX6.

    Error while compiling a native application

    If you have installed an SDK generated from a WEC2013 OS Design built on a system that has the April 2015 update installed, you will most probably encounter this error when trying to compile a native code project targeting the SDK:

    Microsoft.CppCommon.targets(242,5): error MSB6006: "CL.exe" exited with code -1073741515.

    Further analysis shows that -1073741515 in unsigned hex is 0xC0000135 and that value is defined as error STATUS_DLL_NOT_FOUND in Windows:

    #define STATUS_DLL_NOT_FOUND             ((NTSTATUS)0xC0000135L)    // winnt

    So, something is missing a DLL somewhere...

    A compare with an SDK installation generated prior to the installation of the April 2015 WEC update showed that the folder C:\Program Files (x86)\Windows CE Tools\SDKs\[SDK Name]\Sdk\Bin\i386\Arm was missing the file mspdb110.dll. Copying this file manually to the aforementioned folder fixes the problem and you can successfully build the project again.

    If you are still getting errors (like for instance "Fatal Error C1902") after having copied mspdb110.dll, then copy all files from the folder "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE" to the SDK's i386\Arm folder as per above instructions.

    This seems to be a problem with the SDK roller introduced in the April 2015 WEC2013 update.

    Microsoft is aware of the bug and will most likely fix this issue in the next update of WEC2013.

    GuruCE iMX6 BSP now supporting Boundary Devices Nitrogen6X board!

    iMX6
    Our new iMX6 BSP release (r406) now adds initial support for the Boundary Devices Nitrogen6X SBC!

    We also did some work on the bootloader (now you can disable the watchdog in the CE kernel from the bootloader, you can test memory and you can inspect some technical info about image defines, clock gates & frequencies and the iMX6 itself). The problem we had with Ethernet on some Sabre-Lite boards has been fixed and UART DMA is now working properly as well, as is ILTiming. While we were at it, we also slightly improved the real-time performance of the kernel and we fixed some dependencies in the catalog.

    All in all another great release from the experts at GuruCE! Go ahead and download a WEC7 or WEC2013 evaluation kernel for one of the many supported off-the-shelf development kits and SBCs.

    GuruCE and Lauterbach announce their official partnership

    Lauterbach LogoGuruCE Logo

    PRESS RELEASE:
    Hoehenkirchen-Siegertsbrunn, Germany, and Ohiwa, New Zealand, June 2015

    Lauterbach, leading manufacturer of microprocessor development tools, and GuruCE, well-known manufacturer of high quality Microsoft Windows Embedded Compact BSPs, announced a deepening of their relationship in the form of an official partnership between GuruCE and Lauterbach. The experts at GuruCE and Lauterbach already have a long working relationship that is now brought to an even higher level of cooperation.

    Lauterbach's debugging expertise combined with GuruCE's Windows Embedded expertise has been critical in creating a highly reliable and extremely well performing iMX6 BSP for Windows Embedded Compact 7 and 2013.

    GuruCE now ships easy-to-use Lauterbach JTAG scripts with their iMX6 BSP so that GuruCE's customers can, if needed, dive deep with the help of the best JTAG solutions for Windows Embedded Compact by Lauterbach.

    “We at Lauterbach very much enjoy the cooperation with GuruCE. Close contacts between the developers and managers of both companies ensure a fast time-to-market of new solutions, as well as a rapid response to customer support issues”, said Rudi Dienstbeck at Lauterbach.

    “The expertise of Lauterbach has been invaluable in tracking down some very complex issues with L1 and L2 cache coherency in the multi-core iMX6 processors. Without the excellent support & tools of Lauterbach it would have taken us much longer to create a fully multi-core cache-coherent BSP for the iMX6”, said Michel Verhagen at GuruCE.

    About GuruCE
    GuruCE offers deep technical knowledge of Windows Embedded Operating Systems. The consultants of GuruCE are among the best in Windows Embedded BSP & driver development, training and consulting. They help customers overcome the steep learning curve and greatly reduce the time-to-market for their products. GuruCE operates as an umbrella for the top 5% of talented Windows Embedded consultants. Most of the experts working with us are Microsoft MVPs. GuruCE employs local experts in Europe (Netherlands), USA and New Zealand. For more information please visit https://guruce.com

    About LAUTERBACH
    Lauterbach is the leading manufacturer of complete, modular and upgradeable microprocessor development tools worldwide with experience in the field of embedded designs since 1979. It is an international, well-established company with blue chip customers in every corner of the globe and has a close working relationship with all semiconductor manufacturers. At the headquarters in Höhenkirchen, near Munich, the engineering team develops and produces highly proficient and specialized Development Tools, which are utilized all over the world under the brand TRACE32®. Own branch offices exists in United Kingdom, Italy, France, Tunisia, on the East and West coasts of the United States, Japan and China. Highly qualified sales and support engineers are also available in many other countries. For more information visit http://www.lauterbach.com/

    iMX6 BSP now supporting PCIe!

    We have just released a new version of our iMX6 BSP.

    In this release (r363) we have added:

    • PCIe support
    • Digi ConnectCore6 support
    • Device Solutions Opal6 support
    • Many more supported devices like PMIC, touch, displays, etc. and many improvements

    Download our demo kernel images now and see for yourself why the GuruCE iMX6 BSP is the best on the market today!

    Michel Verhagen 2015 MVP

    MVP Logo
    Michel Verhagen has been honoured with the Microsoft MVP Award again this year!


    Congratulations! We are pleased to present you with the 2015 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.

    According to my profile this is now the 12th consecutive year but I think that must be at least 13 (2001 or maybe 2002 was the first if I remember correctly). So long time MVP I can't even remember, but: 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.

    GuruCE High Quality iMX6 WEC7/2013 BSP supporting iMX6 Solo, Dual Lite, Dual and Quad NOW RELEASED!

    iMX6
    After working for more than a year on our iMX6 BSP we are finally ready to put our quality stamp on it and release our iMX6 BSP to our customers!

    Here are the main benefits of our iMX6 BSP compared to the other iMX6 BSP offerings on the market today:

    • Stability
    • Our initial iMX6 BSP release is all about stability. We have done extensive testing to make sure the entire BSP is stable, in multi-core and single-core configurations, with or without caching, at stress and at rest. We have completely rewritten all of the low-level initialization code, all the timing code (CCM, system & performance counters), all of the cache code, all of the SMP (symmetric multiprocessing/multi-core) code and most of the interrupt handling code.

    • Performance
    • We have implemented all the cache optimizations possible for the iMX6 Cortex-A9 in combination with the PL310 L2 Cache Controller and we have configured DDR3 per board at the most optimal, fully stress tested, settings.
      iMX6 Catalog - BSP Options

    • No more data corruption!
    • We have done extensive testing to make sure there are no more data corruption problems when copying large files (on SATA, USB Storage or USDHC) or when sending large amounts of data over the network.

    • One BSP for all iMX6 variants
    • Our BSP supports the iMX6 Solo, Dual Lite, Dual and Quad processor range, so you can scale your HW design up or down without any software development investment!

    • One BSP supporting WEC7 and WEC2013
    • Full drop-in support for WEC7 and WEC2013. Not a single code change required in the BSP.

    • Super easy BSP configuration
    • Very easy configuration of board, bootloader, CPU, cache and page table BSP options through the catalog (see image on the right).

    • Production Quality Code
    • All hardware definitions name-synchronized with the iMX6 Reference Manuals and IOMUX tool. A large amount of Freescale code re-factored, cleaned up & bug fixed, and all redundant code removed and restructured. No more searching for driver code distributed throughout the BSP in different folders. Now the BSP is easily maintainable, well-structured & production ready. If you have worked with BSPs from Freescale or some of our competitors before you know what this means and why this is so important. Code quality and BSP structure is everything!

    • Full source
    • Including all Cortex-A9 cache routines, SMP, drivers, etc.
      We just don't believe in binary. Luke would never have gotten so far if he had to "use the binary"... ;-)

    • Very easy to add support for your custom board
    • All board specific settings in one folder and board file generator included. All you need to support your custom board is an IOMux design file (created with Freescale's IOMux tool for iMX6) and our board file generator that will create a header file with all your board specific settings.

    • SPI Flash/SD/MMC Bootloader
    • Our iMX6 bootloader offers many more configuration options and features, like selecting the serial debug port to use, blowing fuses, configuring the Ethernet settings to be used in Windows Embedded Compact and starting the kernel with a clean registry hive. It also fully supports booting from SPI Flash, SD and MMC, and has full support for formatting and partitioning SD and MMC and erasing/writing SPI Flash.

    • Full support for LCD8000-97C 1024x768 LVDS + capacitive touch screen
    • The BSP includes full support for this display, including touch driver support.

    • Hive based registry support
    • Destination fully configurable through the catalog. No registry modifications required.
      iMX6 Catalog - Storage

    • GPIO driver + SDK library
    • Control any (free) GPIO pin from your application.

    • FlexCAN driver + SDK library
    • Fully configurable FlexCAN driver. Access and control 2 separate CAN buses from your application with full configuration and timing control. Our High Performance FlexCAN driver for real busy CAN buses is available for iMX6 as well.

    • ECSPI driver + SDK library
    • Fully configurable, DMA enabled, Enhanced Configurable SPI driver. All functionality offered by the iMX6 is supported and configurable in our driver. Unfortunately the iMX6 still contains the same silicon bug as on the iMX53, but at least our driver warns you when you hit this condition.

    • GPT driver
    • Use the General Purpose Timer from within your application. Full control over counters, interrupts, etc.

    • USB Camera driver
    • Configured and ready for iMX6.

    • Memory Access Utility driver, SDK and application
    • For easy debugging and direct hardware access from within CE. Similar functionality as memtool in Linux.

    • SATA
    • Fully functional SATA driver with much faster drive detection algorithm.

    • Complete bootloader independence
    • The low-level kernel initialization code takes care of everything needed by Windows Embedded Compact. It does not depend on any configuration done by the bootloader. This means you can choose whatever bootloader you fancy. You can use our included and feature-rich eboot, or any other bootloader you like better.

    • Fully tested DDR3 setup code
    • Per board DDR3 stress testing done (FSL DDR3 Stress Test Tool) and DDR3 configured with optimal settings.

    • Included JTAG scripts for Lauterbach TRACE32
    • Just in case you need it.

    The above is of course on top of the standard functionality:

    • UARTs (5)
    • Audio (SGTL5000)
    • Camera (CMOS)
    • I2C
    • Ethernet
    • USB (Host, Client & OTG)
    • USDHC/SDIO ports (4)
    • Display:
      • Opal6 DevKit
      • HDMI
      • LVDS (including Touch)
      • GPU (HW GFX acceleration)
      • VPU (HW Video acceleration)
      • Silverlight (OpenGL & DDraw)

    Supporting various boards:

    • Supporting the Opal6 module and development board by Device Solutions (iMX6 Dual Lite)
    • Supporting the open source RIoTboard design by Element14 (iMX6 Solo)
    • Supporting the conga-QMX6 modules and development boards by Congatec (iMX6 Solo, Dual Lite, Dual and Quad)
    • Supporting the SABRE Lite board by Element14 (iMX6 Quad)
    • Supporting the BD-SL-iMX6 (formerly known as SABRE-Lite) board by Boundary Devices (iMX6 Quad)

    Our business model
    Our business model is all about delivering a high quality BSP that we fully support and stand behind. We want our customers to be able to get to market quicker, without having to spend an enormous amount of time and money on finding and fixing bugs. We sell & support a high quality, tested BSP and if needed our customers can work with GuruCE to add additional functionality or modify functionality specific to the customers needs.

    MVP Logo
    Dedicated & responsive support from real experts!
    You connect directly to the highest level support engineers that will respond to your query within 48 hours with a high quality answer that will help you, not frustrate you.

    Is it perfect?
    Perfection is something we strive to achieve, but we will not pretend our BSP is perfect. There's always something to improve or functionality to add. This initial release was completely focused on stability and performance. Our next update will add some functionality (PCIe) and focus mostly on power management.

    Below are the things we will work on next, ordered by priority:

    1. PCIe
    2. Develop a flexible, high performance PCIe bus driver and example client driver.

    3. Power Management
    4. Get the cores to the lowest possible power state when in idle to further reduce power dissipation and CPU heat. The first step is to reduce power dissipation in the low power WAIT mode, the next step will be to implement STOP mode, the step after will be to add DVFS support, and the final step will be to make sure the entire system can suspend and resume correctly.

    5. Add support for more boards
    6. Add support for Nitrogen6X, Freescale SDP, Digi CC6, Variscite iMX6 SOMs and possibly more iMX6 boards and modules available from various board and module manufacturers.

    7. Rewrite entire ENET driver
    8. So we fully support NDIS6 and can increase performance.

    9. Rewrite I2C driver
    10. Currently functional, but we would love to add more functionality and create high quality, maintainable code.

    11. Rewrite IPU driver
    12. Currently functional, but we would love to add more functionality so we can support true multi-monitor, dynamic resolution, dynamic switching of output, etc.

    The above list and order can change depending on customer requests.

    Freescale iMX53 and iMX6 ECSPI silicon bug

    Update: We have repeated our tests on iMX6 and unfortunately the same silicon bug is also present on the iMX6, so everything you read here can be applied to the iMX6 as well...

    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.
    The issue is also present on the iMX6.

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

    GuruCE to release a High Quality iMX6 BSP supporting iMX6 Solo, Dual Lite, Dual and Quad

    iMX6
    GuruCE has been working on a high quality iMX6 BSP for WEC2013 since the beginning of 2014, and will be releasing this BSP early 2015.

    Microsoft has just released a SAMPLE BSP for iMX6 through Update 11 for WEC2013, so why would you wait for the GuruCE iMX6 BSP? Here are some compelling reasons:

    • One BSP for all iMX6 variants
    • Our BSP supports the iMX6 Solo, Dual Lite, Dual and Quad processor range, so you can scale your HW design up or down without any software development investment!
      We are contemplating to add support for iMX6 Solo Lite as well. Please let us know if you are interested in having this!

    • Production Quality Code
    • All hardware definitions name-synchronized with the iMX6 Reference Manuals and IOMUX tool. Almost all Freescale code re-factored, cleaned up, bug fixed, redundant code removed and restructured. Now the BSP is easily maintainable, well-structured & production ready. If you have worked with BSPs from Freescale or some of our competitors before you know what this means and why this is so important. Code quality and BSP structure is everything!

    • Full source
    • Including DVFS, GPC, Cache routines, SMP, PCIE and PMU code.
      We just don't believe in binary. Luke would never have gotten so far if he had to "use the binary"...

    • Very easy to add support for your custom board
    • All board specific settings in one folder and board file generator included. All you need to support your custom board is an IOMux design file (created with Freescale's IOMux tool for iMX6) and our board file generator that will create a header file with all your board specific settings.

    • Lots of added functionality and fixes:
    • Opal6 Module

      • GPIO driver + SDK library
      • Control any (free) GPIO pin from your application.

      • FlexCAN driver + SDK library
      • Fully configurable FlexCAN driver. Access and control 2 separate CAN buses from your application with full configuration and timing control. Our High Performance FlexCAN driver for real busy CAN buses is available for iMX6 as well.

      • ECSPI driver + SDK library
      • Fully configurable, DMA enabled, Enhanced Configurable SPI driver. All functionality offered by the iMX6 is supported and configurable in our driver.

      • GPT driver
      • Use any GPT from within your application. Full control over counters, interrupts, etc.

      • USB Camera driver
      • Configured and ready for iMX6.

      • Memory Access Utility driver, SDK and application
      • For easy debugging and direct hardware access from within CE. Similar to memtool in Linux.

      • Full SD & eMMC support
      • Including formatting and partitioning in the bootloader.

      • Complete bootloader independence
      • This means you can choose whatever bootloader you fancy. We support uboot and eboot out-of-the-box.

      • Power optimizations
      • The BSP and bootloader are both optimized for power. No unnecessary open clock gates, full control of CCM (completely rewritten code), DVFS support, etc.

      • Fully tested DDR3 setup code
      • Per board DDR3 stress testing done (FSL DDR3 Stress Test Tool) and DDR3 configured with optimal settings.

      • Organized catalog and added many configuration settings to catalog
      • Click and forget configuration of your OS Design! Configuration options in catalog: CPU type, RAM size, Cache options, ARM errata options.

      • Serial Debug UART selection in bootloader
      • No more unnecessary recompiling of the entire kernel, just to change or disable the debug output serial port.

      • Included JTAG scripts for Lauterbach TRACE32
      • Just in case you need it.

      Opal6 DevKit

    • The above is of course on top of the standard functionality:
      • Audio (SGTL5000)
      • Camera (CMOS)
      • I2C
      • Ethernet
      • PCIe
      • UARTs (5)
      • USB (Host, Client & OTG)
      • USDHC/SDIO ports (4)
      • Display:
        • HDMI
        • LVDS (including Touch)
        • GPU (HW acceleration)
        • VPU (Video acceleration)
        • Silverlight (OpenGL & DDraw)

    • Supporting the Opal6 module and development board by Device Solutions (iMX6 Dual Lite)
    • Supporting the open source RIoTboard design by Element14 (iMX6 Solo)
    • Supporting the conga-QMX6 modules and development boards by Congatec (iMX6 Solo, Dual Lite, Dual and Quad)
    • Supporting the SABRE Lite board by Element14 (iMX6 Quad)
    • Supporting the BD-SL-iMX6 (formerly known as SABRE-Lite) board by Boundary Devices (iMX6 Quad)
    • Supporting the Sabre-SDP board by Freescale (iMX6 Dual Lite and Quad)
    • And last but certainly not least:
      MVP Logo

    • Dedicated & responsive support from real experts!
    • You connect directly to the highest level support engineers.

    WEC2013 GenSdk build error

    We recently ran into an issue with generating an SDK for WEC2013. The error message displayed wasn't very helpful:

    Error: GenSdk build error: Error HRESULT E_FAIL has been returned from a call to a COM component.

    In Visual Studio 2013 the error looks like this:

    With the help of Microsoft we managed to determine the SDK roller (GenSDK) couldn't find some required files and that was causing the failure. The "Build SDK tools" use some input/template files and folders to generate an SDK. It seems that it cannot build an SDK because some files/folders were deleted by the SDK build tools. This is confirmed to be a bug now... To fix this issue we need to regenerate the files and then rename a folder.

    Here are the steps to fix this problem for now:

    • Regenerate the files
    • When you build your solution the build process prepares the files needed for SDK generation by copying templates to the $(SG_OUTPUT_ROOT)\misc\sdk folder.

      In my test OSDesign the full path is: $(_WINCEROOT)\OSDesigns\TestCEPC\TestCEPC\Wince800\TestCEPC_x86_Retail\cesysgen\misc\sdk

      When you get the error Error: GenSdk build error: Error HRESULT E_FAIL has been returned from a call to a COM component this is because your $(SG_OUTPUT_ROOT)\misc\sdk folder has been corrupted. To fix this we need to regenerate the correct files. To do this you can either:

    1. Build your solution. This will generate the files in the correct place
    2. Copy the files manually
    3. Copy the contents from $(WINCEROOT)\public\common\sdk\msbuild\$(_TGTCPU)\sdk_name into the $(SG_OUTPUT_ROOT)\misc\sdk\msbuild\sdk_name folder.

    When everything is as it should be, the folder should look like this:

  • Rename the sdk_name folder
  • When the files are in the correct place you need to capitalize the sdk_name folder. In other words; rename it to SDK_NAME.

    So;

    Rename $(SG_OUTPUT_ROOT)\misc\sdk\msbuild\$(_TGTCPUFAMILY)\sdk_name to $(SG_OUTPUT_ROOT)\misc\sdk\msbuild\$(_TGTCPUFAMILY)\SDK_NAME.

    The reason for this is that the GenSDK managed code uses case-sensitive functions to search for the correct folder name. If the folder name is not all uppercase it will delete it!

    When you've renamed the folder you can now build your SDK again and all should be working fine!

    Microsoft is currently creating the update that will fix all of the above discovered problems.

    DISCLAIMER: This is a workaround, not a final solution. It will be fixed in one of the next updates. Please let me know if you find any issues with this workaround by leaving a comment below, thanks!

    Error installing WEC2013 SDK: You must install Windows Embedded XAML Tools before you can proceed with this SDK installation

    So, you've just updated your Visual Studio 2013 and WEC2013 installations and have generated an SDK for your OS Design. Now you install the SDK and you get this error message: "You must install Windows Embedded XAML Tools before you can proceed with this SDK installation."

    Very annoying, and this is something that started being a problem with one of the later (post Update 5) updates for WEC2013. I did not have time to figure out exactly what is causing this issue (most probably some mismatching version information of the XAML toolset), but I did find a workaround:

    Use Orca (or any other msi editor) to remove the Custom Action named "CA_CheckPreReqWEXTInstalled".

    Orca is in the Microsoft Windows SDK which should be on your machine if you've installed Visual Studio. Take a look in your "Program Files (x86)" folder and search for "orca". You should find "Orca-x86_en_us.msi", or something similar (depending on what VS version you have installed). If you can't find anything make sure to install Visual Studio or download the Microsoft Windows SDK here.

    Once you've installed Orca you can right click the SDK msi and choose "Edit with Orca". When Orca opens you'll have to select the "CustomAction" table on the left and select the row with action "CA_CheckPreReqWEXTInstalled":

    Now press the delete key and a dialog should pop up asking you if you really want to permanently remove this row from the database:

    Click OK, save the modified msi and exit Orca.

    Now the SDK will install without problems.

    DISCLAIMER: This is a workaround, not a final solution. I'm pretty sure it will all work just fine with the latest (mismatching version number) XAML tools, but I haven't checked it. Please let me know if you find any issues with this workaround by leaving a comment below, thanks!

    What to build when in WEC2013

    [This is an update of a blog post I wrote a long time ago. Check the comments under that post if you have any questions (or comment on this post if your question is not answered in the old post)]

    A question that keeps coming back on the forums is "I changed some code, but it does not end up in my image", or "I changed some registry values in platform.reg, but if I look at the device registry, it's not there!", or even "Why does a kernel build take so long?".

    The source of these problems is build-related. You've got to understand the build system in order to know exactly what to do. This blog post aims to give you a clear handle on "What to build when"!

    At first glance, WEC2013 seems to only offer two build command: "Build Solution" and "Rebuild Solution". There are however a lot more variations that can save you a tremendous amount of time in your day-to-day work with Visual Studio 2013 and Platform Builder.

    Before we dive into build system commands and how to use them I'd like to make sure you understand you should never modify code in the PUBLIC or PRIVATE trees. If you need to change functionality in those code trees it is very important you clone that code to your BSP folder or OS Design folder first. The main reason is that changing code in the PUBLIC or PRIVATE folder will not result in the code changes to be automatically build and included in your kernel image. You'd have to manually build that code, make sure the updated libraries, dlls and/or exes are in the right place, and then rebuild your kernel. The reason why this can cause many problems is because any WEC update may overwrite your code changes and maintenance is a nightmare.

    So, keep this in mind:

    Never change code in the PUBLIC or PRIVATE trees; always clone to your BSP or OS Design first!

    For help with this process see the following blog posts:

    Cloning public code: An example
    Manual Clone of Public Code
    Cloning CalibrUi in Windows CE 6.0 (this may need some updating for WEC2013 but it will give you an idea)

    In all the versions before WEC2013 Microsoft included build commands in the Advanced Build menu that would execute "blddemo" without the "-q" parameter. This results in the ENTIRE WINCEX00 tree being built, thereby overwriting many libraries, DLLs and EXEs that shipped as binary with CE/EC. After years of protest by all the embedded MVPs we finally managed to convince MS that these commands should be erased from the IDE. However, you can of course still execute blddemo without -q on the command line. This command is, and always has been, very dangerous because sometimes the binaries do not match the actual source code. This can happen when an update updates some libraries, but not the source code. This *should* not happen, but it does happen over and over again. Executing "blddemo" without the "-q" parameter will result in your CE tree being in an undetermined state and the only solution is a complete uninstall and reinstall of CE/EC. So, if you're working from the command line; NEVER EVER execute blddemo without the -q parameter! If you're not working from the command line; no worries!

    Phew! Now that we got that out of the way let's see what build command we've got to use in what situation:

    WEC2013 Build Commands

    • Create a new OS Design (or add a new build configuration to an existing OS Design): Sysgen (Build Solution)
    • Since a new OS Design doesn't have anything in its build configuration's output folders (same with a new build configuration) you'll have to sysgen the entire solution (for that build configuration). The longest process, but luckily you don't have to do this many times (see below).

    • Change Platform Settings: Make image
    • Platform Settings
      If you change any Platform Settings (like IMGNOKITL, IMGNODEBUGGER, IMGPROFILER) all you have to do is a Make Image.

    • Change driver source code in your BSP: Build the driver and Make Image
    • If you change driver source code, all you have to do is just build the driver (WINCEREL must be set to 1 but it is set by default so unless you changed it there's no need to worry) and do a makeimg. If you only want to debug the driver you can also add the DLL to the Release Directory Modules list (menu Tools) and just restart the device (or reload the device driver on the device) without having to do a makeimg and download to device. Building just the driver is a simple right-click on the driver and Build in the IDE or "build" in the driver's folder on the command line.

    • Change multiple source code files in your BSP: Build the BSP and Make Image
    • The safe option, this way you can't forget to rebuild anything. Building the BSP is a simple right-click on the PLATFORM\BSP folder and Build in the IDE or "build" in the BSP's root folder on the command line.

    • Change platform.reg, bib, dat or db files in your BSP: Sysgen the BSP, Copy Files to Release Directory, Build All Subprojects and Make Image
    • A lot of steps, but this will still not take longer than a couple of minutes. If you change any of the platform.* files we need to re-filter (Sysgen) those files and make sure the filtered files are copied into the FLATRELEASEDIR (Copy Files to Release Directory). That last action did however clear the project binaries from the FLATRELEASEDIR so we need to make sure those binaries and settings are getting copied into the FLATRELEASEDIR again (Build All Subprojects) and finally we are ready to Make Image. Now your registry changes will be in the image (check reginit.ini to make sure, last entry wins).

    • Change some source files and platform.reg, bib, dat or db files in your BSP: Build and Sysgen the BSP, Copy Files to Release Directory, Build All Subprojects and Make Image
    • Only difference with previous situation is that you now have to build the BSP to include the source code changes.

      The "Build and Sysgen BSP" command can be executed by right clicking your BSP root node in the Solution Explorer and choosing "Build and Sysgen (cebuild -qbsp)". Notice the -q in that command? That shows you it's a good command...

    • Change the workspace configuration (add or delete a component): Sysgen the entire workspace (Build solution)
    • For most components a simple Sysgen is enough. For some components (like when changing from RAM based registry to Hive based Registry) a Clean Sysgen is needed. This action takes the longest (anywhere from 5 minutes for a small workspace configuration on a very fast machine to a couple of hours for a really big configuration and a very slow machine). A Sysgen is a right-click on the workspace, Advanced Build Commands->Sysgen in the IDE or "blddemo -q" on the command line.

    • After installing one or multiple WEC updates: Clean Sysgen the entire workspace (Rebuild solution)
    • To make sure all components are re-linked with the (possibly updated) libraries a Clean Sysgen is needed. This action takes the longest (anywhere from 5 minutes for a small workspace configuration on a very fast machine to a couple of hours for a really big configuration and a very slow machine). A Clean Sysgen can be performed by choosing Rebuild Solution from the build menu, or choosing Advanced Build Commands->Clean Sysgen in the IDE or "blddemo clean -q" on the command line.

    Sometimes it's easier to build from the command line. If you are unsure what command to type you can always perform the action in the IDE first and watch the 3rd line in the build output window starting with "Starting Build:". Behind the colon is the exact command line for that action, eg Sysgen on the BSP: "Starting Build: SysgenPlatform %_TARGETPLATROOT% preproc&&SysgenPlatform %_TARGETPLATROOT% postproc", so on the command line you would type "SysgenPlatform %_TARGETPLATROOT% preproc" followed by enter and the 2nd command "SysgenPlatform %_TARGETPLATROOT% postproc" followed by enter.

    If you use the commandline, make sure you never forget "-q" when running "blddemo"!

    I hope this blog post will help you speed up your builds and lower your frustration with the build system!

    PS. Also check out this tip (works for WEC2013 too) to further improve build speed if your BSP is using code from the PLATFORM\COMMON\SRC\SOC folders.

    Good luck!

    A template for debug messages

    In all the drivers and applications we develop here at GuruCE, we always take the time to add plenty of logging because we know good logging will save us loads of time debugging our code (not that we ever have to debug code here of course... ;)).

    Windows CE has a really great mechanism for debug logging called Debug Zones. This mechanism allows you to divide your debug messages into 16 zones and each of these zones can be turned on or off at run-time. This allows you to control the verbosity of your debug output and helps prevent cluttering of messages. Read this excellent blog post by Travis first before reading on: http://blogs.msdn.com/ce_base/archive/2006/12/18/debug-messages-and-debu...

    To add debug logging using Debug Zones to your application or driver do the following:

    1. Define your zones using the DEBUGZONE macro
    1. Define a DBGPARAM structure and fill it
    2. Call either DEBUGREGISTER or RETAILREGISTERZONES from your DllMain (driver) or WinMain (application)
    3. Log messages using either DEBUGMSG or RETAILMSG

    Sounds easy (and actually it is) but to make it more easy (and because we found ourselves doing the same thing over and over) we created a template we now use in all our driver and application code, even on projects targeted for Desktop Windows. Even though "Big" Windows doesn't have a "Debug Zone" mechanism you can still use the template. The big benefit of course being that your code is completely portable between desktop PC's and CE devices (and also MBS/UNICODE)! The only thing you can't do is switch debug zones at run-time, but you can still select which zones should be on or off at compile-time.

    We have released these templates under GPL for the greater good.

    Let us explain the template by walking through it; we'll start with DebugZones.cpp (the line numbers reflect the actual line numbers in the template files):

    1. #include <windows.h>
    2. #include "DebugZones.h"
    3.  
    4. // Do NOT change anything in this file.
    5. // See DebugZones.h for things you can change!
    6. /*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
    7. extern "C" DBGPARAM dpCurSettings =
    8. {
    9.     __WMODULE__,
    10.     {
    11.         ZONE0_TEXT, ZONE1_TEXT, ZONE2_TEXT, ZONE3_TEXT,
    12.         ZONE4_TEXT, ZONE5_TEXT, ZONE6_TEXT, ZONE7_TEXT,
    13.         ZONE8_TEXT, ZONE9_TEXT, ZONE10_TEXT, ZONE11_TEXT,
    14.         ZONE12_TEXT, ZONE13_TEXT, ZONE14_TEXT, ZONE15_TEXT
    15.     },
    16. #ifndef DEBUG // IN RETAIL...
    17.     RETAILZONES
    18. #else //IN DEBUG...
    19.     DEBUGZONES
    20. #endif
    21. };

    The first and most important thing to note is that you should not change anything in this file. You configure the template all through the header file, which we'll will be discussing later.

    In this first part of DebugZones.cpp we simply define a global variable dpCurSettings of type DBGPARAM and fill the structure with defines from DebugZones.h. The __WMODULE__ corresponds to the "lpszName" member, the ZONEx_TEXT defines fill the "rglpszZones" array and finally RETAILZONES or DEBUGZONES (depending on whether you build a "debug" or "release" version of the code) corresponds to the "ulZoneMask" member of the DBGPARAM structure. The CE debug system uses this structure to get Debug Zone information from the module and to set or clear debug zones during execution of the module. When you use the template for code targeted at Desktop Windows this structure will only be used by the DEBUGMSG/RETAILMSG macros (they use the ulZoneMask member as a display condition).

    1. #ifndef UNDER_CE
    2.   #include <stdio.h>
    3.   void WINAPIV NKDbgPrintf(LPCTSTR lpszFmt, ...)
    4.   {
    5.       #define BUFFER_SIZE 1000
    6.       va_list argptr;
    7.       va_start(argptr, lpszFmt);
    8.       TCHAR szBuffer[BUFFER_SIZE];
    9.       _vstprintf_s(szBuffer, BUFFER_SIZE, lpszFmt, argptr);
    10.       OutputDebugString(szBuffer);
    11.       va_end(argptr);
    12.   }
    13. #endif

    This code is only used when you target Desktop Windows. Only Windows CE defines NKDbgPrintf so for Desktop Windows we had to create our own implementation of this function to make the Debug Zones system portable. This function simply takes a format string followed by a variable number of parameters and transforms that into a formatted string and outputs it to the debug output window of Visual Studio. Note that the maximum length of the formatted string is BUFFER_SIZE characters.

    1. // Helper function for runtime conversion of char* to _T
    2. LPCTSTR to_T(LPCSTR pStr)
    3. {
    4.     #define MAX_CALLS   4
    5.     #define MAX_MSG     500
    6.  
    7.     static TCHAR buffer[MAX_CALLS][MAX_MSG];
    8.     static DWORD index = 0;
    9.     LPCTSTR pszRet = buffer[index];
    10.     size_t conv;
    11.  
    12.     #ifdef UNICODE
    13.       mbstowcs_s(&conv, buffer[index], MAX_MSG, pStr, MAX_MSG);
    14.     #else //ANSI
    15.       strcpy_s(buffer[index], MAX_MSG, pStr);
    16.     #endif
    17.  
    18.     index++;
    19.     if (MAX_CALLS==index)
    20.         index = 0;
    21.     return pszRet;
    22. }

    This next bit of code is a helper function that solves a problem when you want your code to be portable between MBS and UNICODE. MBS is multi-byte string, also called ANSI string, and UNICODE is, well, UNICODE strings. Let's say you are compiling for UNICODE but want to display a multi-byte string using a function that uses a format string. The way to do that is to use %S instead of %s in the format string. When you use %s in code compiled for UNICODE the variable indicated by %s should be in UNICODE. When you compile for MBS the variable indicated by %s should be MBS. In other words, %s indicates the "native" string format. If you want to display a multi-byte string in code compiled for UNICODE you'd use %S, and if you want to display a UNICODE string in code compiled for MBS you'd use %S as well. In other words, %S indicates the "opposite" string format. And here lies the problem: What if you want to display a multi-byte string regardless of whether the code is compiled for MBS or UNICODE?

    Take a look at the following code:

    NKDbgPrintf(_T("Display a native format string \"%s\"\r\n"), _T("This is a native string format"));
    NKDbgPrintf(_T("Display opposite string format \"%S\"\r\n"), "This is a multi-byte string");

    Note that the _T macro is defined as L in UNICODE (making the following string a UNICODE string) and as nothing in MBS (leaving the following string a multi-byte string).

    When compiled for UNICODE the above code works perfectly:

    Display a native format string "This is a native string format"
    Display opposite string format "This is a multi-byte string"

    But now see what happens when you compile the above code for MBS:

    Display a native format string "This is a native string format"

    You only get the output of the first line! So what just happened? Well, the _vstprintf_s function in NKDbgPrintf expected the first argument to be of the opposite string format. Since you compiled for MBS this means it expects a UNICODE string. The _vstprintf_s function detects it is not and bails out, setting szBuffer to an empty string.

    The to_T function solves this problem:

    NKDbgPrintf(_T("Display a native format string \"%s\"\r\n"), _T("This is a native string format"));
    NKDbgPrintf(_T("Display opposite string format \"%s\"\r\n"), to_T("This is a multi-byte string"));

    When compiled for MBS the output is:

    Display a native format string "This is a native string format"
    Display opposite string format "This is a multi-byte string"

    I can hear you say: So why don't you just use _T() in that 2nd call to NkDbgPrintf? And yes, you are right, in the above code that would work, but what if it's a variable pointing to a multi-byte string? You can't use _T() around a variable:

    NKDbgPrintf(_T("IPAddress \"%s\"\r\n"), to_T(inet_ntoa(ipAddress)));

    Line 67 defines the maximum number of times you can call this function before it will start overwriting its internal buffers. Increase this value if you want to use more than 4 parameters that need to be converted in one call. To understand this, see the following code and its output:

    char* s1 = "String 1";
    char* s2 = "String 2";
    char* s3 = "String 3";
    char* s4 = "String 4";
    char* s5 = "String 5";
    char* s6 = "String 6";

    NKDbgPrintf(_T("%s %s %s %s %s %s\r\n"), to_T(s1), to_T(s2), to_T(s3), to_T(s4), to_T(s5), to_T(s6));

    Output:

    String 1 String 2 String 3 String 4 String 1 String 2



    Let's move on to the real core of the template; DebugZones.h:

    1. #pragma once
    2. #include <windows.h>
    3.  
    4. // Change the following definitions:
    5. /*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
    6. #define __MODULE__ "MyDriver"  // The module name
    7.  
    8. // Define this to issue a DEBUHCHK(FALSE) when printing an ERRMSG and/or WRNMSG
    9. //#define DEBUGCHK_ON_ERRMSG
    10. //#define DEBUGCHK_ON_WRNMSG
    11.  
    12. // Definitions for our debug zones                              
    13. #define ZONE0_TEXT          _T("Init")
    14. #define ZONE1_TEXT          _T("Function")
    15. #define ZONE2_TEXT          _T("Memory")
    16. #define ZONE3_TEXT          _T("")
    17. #define ZONE4_TEXT          _T("")
    18. #define ZONE5_TEXT          _T("")
    19. #define ZONE6_TEXT          _T("")
    20. #define ZONE7_TEXT          _T("")
    21. #define ZONE8_TEXT          _T("")
    22. #define ZONE9_TEXT          _T("")
    23. #define ZONE10_TEXT         _T("")
    24. #define ZONE11_TEXT         _T("")
    25. #define ZONE12_TEXT         _T("")
    26. #define ZONE13_TEXT         _T("Info")
    27. #define ZONE14_TEXT         _T("Warning")
    28. #define ZONE15_TEXT         _T("Error")
    29.  
    30. // These macros can be used as condition flags for LOGMSG
    31. #define ZONE_INIT           DEBUGZONE(0)
    32. #define ZONE_FUNCTION       DEBUGZONE(1)
    33. #define ZONE_MEMORY         DEBUGZONE(2)
    34. #define ZONE_3              DEBUGZONE(3)
    35. #define ZONE_4              DEBUGZONE(4)
    36. #define ZONE_5              DEBUGZONE(5)
    37. #define ZONE_6              DEBUGZONE(6)
    38. #define ZONE_7              DEBUGZONE(7)
    39. #define ZONE_8              DEBUGZONE(8)
    40. #define ZONE_9              DEBUGZONE(9)
    41. #define ZONE_10             DEBUGZONE(10)
    42. #define ZONE_11             DEBUGZONE(11)
    43. #define ZONE_12             DEBUGZONE(12)
    44. #define ZONE_INFO           DEBUGZONE(13)
    45. #define ZONE_WARNING        DEBUGZONE(14)
    46. #define ZONE_ERROR          DEBUGZONE(15)
    47.  
    48. // These macros can be used to indicate which zones to enable by default (see RETAILZONES and DEBUGZONES below)
    49. #define ZONEMASK_INIT       ZONEMASK(0)
    50. #define ZONEMASK_FUNCTION   ZONEMASK(1)
    51. #define ZONEMASK_MEMORY     ZONEMASK(2)
    52. #define ZONEMASK_3          ZONEMASK(3)
    53. #define ZONEMASK_4          ZONEMASK(4)
    54. #define ZONEMASK_5          ZONEMASK(5)
    55. #define ZONEMASK_6          ZONEMASK(6)
    56. #define ZONEMASK_7          ZONEMASK(7)
    57. #define ZONEMASK_8          ZONEMASK(8)
    58. #define ZONEMASK_9          ZONEMASK(9)
    59. #define ZONEMASK_10         ZONEMASK(10)
    60. #define ZONEMASK_11         ZONEMASK(11)
    61. #define ZONEMASK_12         ZONEMASK(12)
    62. #define ZONEMASK_INFO       ZONEMASK(13)
    63. #define ZONEMASK_WARNING    ZONEMASK(14)
    64. #define ZONEMASK_ERROR      ZONEMASK(15)
    65.  
    66. #define RETAILZONES     ZONEMASK_INIT | ZONEMASK_WARNING | ZONEMASK_ERROR
    67. #define DEBUGZONES      RETAILZONES | ZONEMASK_FUNCTION | ZONEMASK_MEMORY | ZONEMASK_INFO
    68.  
    69. // Define FULL_CONTEXT to show full context in debug messages:
    70. // "Module: [full path to file name:line number] Function>"
    71. //#define FULL_CONTEXT
    72. /*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

    This is the part of the template you should change to match your driver or application. First, in line 33, change the __MODULE__ define to the name of your driver or application. If you are creating a flash driver you'd set this to "FLASH" for instance.

    Uncomment line 36 and/or 37 to generate a DEBUGCHK whenever you use ERRMSG and/or WRNMSG. You'd usually only uncomment these lines when you are in the development stage (when you're still actively debugging your code).

    Next, in lines 40 to 55, you define the friendly names of the debug zones you want. These names will show up when you use the Debug Zones dialog or the "zo" command from Platform Builder. The predefined ones are always useful:

    • Init
    • Use this zone to display debug messages during the initialization phase of your driver. I use this zone in the Init function of drivers.

    • Function
    • This zone is used to display function entry and exit. Used by the FUNC_ENTRY and FUNC_EXIT macros (I'll discuss those later)

    • Memory
    • This zone is used to display memory allocation and de-allocation. Having a separate zone for memory really helps in identifying memory leaks or memory related problems in your driver or application (besides CeDebugX)

    • Info
    • This zone is used to display general information. I use this zone a lot through-out my code and enabling this zone usually means I get heaps of debug messages, but also heaps of information about the flow of my code

    • Warning
    • Use this zone for non-fatal errors (also known as warnings ;o)

    • Error
    • Use this zone for fatal errors; situations where you had to abort a certain operation

    Another zone I use often is "IOCTL". If my driver handles custom IOCTLs I use that zone to display information when those IOCTLs are handled. If you want to add the IOCTL zone you'd change line 43 to:

    1. #define ZONE3_TEXT          _T("IOCTL")

    Lines 58 to 73 define the actual zone IDs. You use these defines as the first parameter of LOG_MSG (that I'll discuss later) to indicate the zone this message belongs to. After you added the IOCTL zone to the friendly names list, you'd change line 61 to:

    1. #define ZONE_IOCTL          DEBUGZONE(3)

    Lines 76 to 91 define the zone masks. You use these defines to indicate which zones should be enabled by default. After you added the IOCTL zone to the zone ID list, you'd change line 79 to:

    1. #define ZONEMASK_IOCTL      ZONEMASK(3)

    Line 93 and 94 define the default zones to use in a release build and a debug build. I enable zones INIT, WARNING and ERROR in a release build and add FUNCTION, MEMORY and INFO to debug builds. Note that in a "ship" build (on Windows CE, WINCESHIP=1) debug/retail messages are defined as "nothing" (so all the logging code is effectively removed from the final binary).

    If you define FULL_CONTEXT (line 98) the LOGMSG macro will output the full path to the source code filename in front of the message, instead of just the module name. We don't enable this by default because it makes the debug output cluttered and less readable (but it can be very handy in some cases).

    This concludes the part of DebugZones.h that you should change. The remainder of the code mostly deals with the differences between Desktop Windows and Windows CE:

    1. // Do NOT change any of the following definitions:
    2. /*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
    3. LPCTSTR to_T(LPCSTR pStr);
    4.  
    5. #ifdef UNDER_CE
    6.   #ifndef DEBUG
    7.     #ifdef __cplusplus
    8.       extern "C" DBGPARAM dpCurSettings;
    9.     #else //!__cplusplus
    10.       extern DBGPARAM dpCurSettings;
    11.     #endif __cplusplus
    12.   #endif DEBUG
    13. #else // !UNDER_CE
    14.     #include <tchar.h>
    15.     #include <stdio.h>
    16.  
    17.     typedef struct _DBGPARAM {
    18.             TCHAR       lpszName[32];           // @field Name of module
    19.             TCHAR   rglpszZones[16][32];    // @field names of zones for first 16 bits
    20.             ULONG   ulZoneMask;             // @field Current zone Mask
    21.     } DBGPARAM, *LPDBGPARAM;
    22.  
    23.     #ifndef DEBUG
    24.       #ifdef _DEBUG
    25.         #define DEBUG
    26.       #endif _DEBUG
    27.     #endif DEBUG
    28.  
    29.     extern DBGPARAM dpCurSettings;
    30.     void WINAPIV NKDbgPrintf(LPCTSTR lpszFmt, ...);
    31.  
    32.     #define RETAILMSG(cond,printf_exp)   \
    33.        ((cond)?(NKDbgPrintf printf_exp),1:0)
    34.  
    35.     #define DEBUGZONE(n)  (dpCurSettings.ulZoneMask & (0x00000001<<(n)))
    36.  
    37.     #define RETAILREGISTERZONES(hMod)
    38.  
    39.     #ifdef DEBUG
    40.         #define DEBUGMSG(cond,printf_exp)   \
    41.            ((void)((cond)?(NKDbgPrintf printf_exp),1:0))
    42.        
    43.         #define DBGCHK(module,exp) \
    44.            ((void)((exp)?1:(          \
    45.                NKDbgPrintf ( _T("%s: DEBUGCHK failed in file %s at line %d \r\n"), \
    46.                          module, _T(__FILE__) ,__LINE__ ),    \
    47.                DebugBreak(), \
    48.                    0  \
    49.            )))
    50.  
    51.         #define DEBUGCHK(exp) DBGCHK(dpCurSettings.lpszName, exp)
    52.         #define DEBUGREGISTER(hMod)
    53.     #endif DEBUG
    54. #endif
    55.  
    56. #ifndef __FUNCTION__
    57. #define __FUNCTION__ __FILE__
    58. #endif __FUNCTION__
    59.  
    60. #ifdef UNICODE
    61.   #define PREPW(x) L ## x
    62. #else //!UNICODE
    63.   #define PREPW(x) x
    64. #endif UNICODE
    65.  
    66. #define TOWSTR(x) PREPW(x)
    67. #ifndef __WFUNCTION__
    68. #define __WFUNCTION__ TOWSTR(__FUNCTION__)
    69. #endif __WFUNCTION__
    70. #define __WMODULE__ TOWSTR(__MODULE__)
    71. #ifndef __WFILE__
    72. #define __WFILE__ TOWSTR(__FILE__)
    73. #endif __WFILE__
    74.  
    75. #define ZONEMASK(n) (0x00000001<<(n))
    76.  
    77. #ifdef FULL_CONTEXT
    78.   #define FUNC_ENTRY(fmt, ...)    RETAILMSG(ZONE_FUNCTION, (__WMODULE__ _T(": +[") __WFILE__ _T(":%d] ") __WFUNCTION__ _T("(") fmt _T(")+\r\n"), __LINE__, __VA_ARGS__))
    79.   #define FUNC_EXIT(fmt, ...)     RETAILMSG(ZONE_FUNCTION, (__WMODULE__ _T(": -[") __WFILE__ _T(":%d] ") __WFUNCTION__ _T("(") fmt _T(")-\r\n"), __LINE__, __VA_ARGS__))
    80.   #define LOGMSG(cond, fmt, ...)  RETAILMSG(cond, (__WMODULE__ _T(":  [") __WFILE__ _T(":%d] ") __WFUNCTION__ _T("> ") fmt, __LINE__, __VA_ARGS__))
    81.   #ifdef DEBUGCHK_ON_ERRMSG
    82.     #define WRNMSG(fmt, ...)        {RETAILMSG(ZONE_WARNING, (__WMODULE__ _T(":  [") __WFILE__ _T(":%d] ") __WFUNCTION__ _T("> WARNING: ") fmt, __LINE__, __VA_ARGS__)); DEBUGCHK(FALSE);}
    83.     #define ERRMSG(fmt, ...)        {RETAILMSG(ZONE_ERROR, (__WMODULE__ _T(":  [") __WFILE__ _T(":%d] ") __WFUNCTION__ _T("> ERROR: ") fmt, __LINE__, __VA_ARGS__)); DEBUGCHK(FALSE);}
    84.   #else // !DEBUGCHK_ON_ERRMSG
    85.     #define WRNMSG(fmt, ...)        RETAILMSG(ZONE_WARNING, (__WMODULE__ _T(":  [") __WFILE__ _T(":%d] ") __WFUNCTION__ _T("> WARNING: ") fmt, __LINE__, __VA_ARGS__))
    86.     #define ERRMSG(fmt, ...)        RETAILMSG(ZONE_ERROR, (__WMODULE__ _T(":  [") __WFILE__ _T(":%d] ") __WFUNCTION__ _T("> ERROR: ") fmt, __LINE__, __VA_ARGS__))
    87.   #endif
    88. #else
    89.   #define FUNC_ENTRY(fmt, ...)    RETAILMSG(ZONE_FUNCTION, (__WMODULE__ _T(": +") __WFUNCTION__ _T("(") fmt _T(")+\r\n"), __VA_ARGS__))
    90.   #define FUNC_EXIT(fmt, ...)     RETAILMSG(ZONE_FUNCTION, (__WMODULE__ _T(": -") __WFUNCTION__ _T("(") fmt _T(")-\r\n"), __VA_ARGS__))
    91.   #define LOGMSG(cond, fmt, ...)  RETAILMSG(cond, (__WMODULE__ _T(":  ") __WFUNCTION__ _T("> ") fmt, __VA_ARGS__))
    92.   #ifdef DEBUGCHK_ON_ERRMSG
    93.     #define WRNMSG(fmt, ...)        {RETAILMSG(ZONE_WARNING, (__WMODULE__ _T(":  ") __WFUNCTION__ _T("> WARNING: ") fmt, __VA_ARGS__)); DEBUGCHK(FALSE);}
    94.     #define ERRMSG(fmt, ...)        {RETAILMSG(ZONE_ERROR, (__WMODULE__ _T(":  ") __WFUNCTION__ _T("> ERROR: ") fmt, __VA_ARGS__)); DEBUGCHK(FALSE);}
    95.   #else // !DEBUGCHK_ON_ERRMSG
    96.     #define WRNMSG(fmt, ...)        RETAILMSG(ZONE_WARNING, (__WMODULE__ _T(":  ") __WFUNCTION__ _T("> WARNING: ") fmt, __VA_ARGS__))
    97.     #define ERRMSG(fmt, ...)        RETAILMSG(ZONE_ERROR, (__WMODULE__ _T(":  ") __WFUNCTION__ _T("> ERROR: ") fmt, __VA_ARGS__))
    98.   #endif
    99. #endif
    100. /*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

    The interesting part is from line 190 to 199 where we define a couple of macros that allow you to log messages in a good and consistent format:

    • FUNC_ENTRY
    • Usage:

      FUNC_ENTRY(format_string [, arg1, arg2, ...]);

      Examples:
      FUNC_ENTRY(_T("void"));
      FUNC_ENTRY(_T("lpParameter = 0x%08X"), lpParameter);

      Output:
      (Note the '+' characters that indicate function entry)
      ModuleName: +FunctionName(void)+
      ModuleName: +FunctionName(lpParameter = 0xA5A5A5A5)+

    • FUNC_EXIT
    • Usage:

      FUNC_EXIT(format_string [, arg1, arg2, ...]);

      Examples:
      FUNC_EXIT(_T(""));
      FUNC_EXIT(_T("return %s"), bRet ? _T("true") : _T("false"));

      Output:
      (Note the '-' characters that indicate function exit)
      ModuleName: -FunctionName()-
      ModuleName: -FunctionName(return false)-

    • LOGMSG
    • Usage:

      LOGMSG(ZONE_ID, format_string [, arg1, arg2, ...]);

      Examples:
      LOGMSG(ZONE_INIT, _T("Started successfully!\r\n"));
      LOGMSG(ZONE_INFO, _T("dwID = %d\r\n"), dwID);

      Output:
      ModuleName:  FunctionName> Started successfully!
      ModuleName:  FunctionName> dwID = 1234

    • ERRMSG
    • Examples:

      ERRMSG(_T("Invalid parameter (dwParam = %d)\r\n"), dwParam);

      Output:
      ModuleName:  FunctionName> ERROR: Invalid parameter (dwParam = 1234)

    • WRNMSG
    • Examples:

      WRNMSG(_T("Could not reach IP %s\r\n"), to_T(inet_ntoa(IPAddress)));

      Output:
      ModuleName:  FunctionName> WARNING: Could not reach IP 10.0.0.1

    To use the Debug Zones template in your projects you simply add DebugZones.cpp and DebugZones.h to your solution and call RETAILREGISTERZONES(hMod) from your entry point function:

    BOOL WINAPI DriverEntry(HANDLE hInstance, DWORD dwReason, LPVOID lpReserved)
    {
        FUNC_ENTRY(_T("hInstance = 0x%08X, dwReason = 0x%08X"), hInstance, dwReason);

        switch(dwReason)
        {
        case DLL_PROCESS_ATTACH:
        {
            // Disable thread creation/deletion calls into this function
            DisableThreadLibraryCalls((HMODULE)hInstance);
            // Register with debug subsystem
            RETAILREGISTERZONES((HMODULE)hInstance);
            break;
        }
        case DLL_PROCESS_DETACH:
        {
            break;
        }
        default:
            break;
        }

        FUNC_EXIT(_T("TRUE"));
        return TRUE;
    }

    or in case of an application:

    int WINAPI WinMain (HINSTANCE hInstance,
                        HINSTANCE hInstPrev,
                        LPWSTR pCmdLine,
                        int nCmdShow)
    {
        // Register with debug subsystem
        RETAILREGISTERZONES(NULL);
        .
        .
        .

    Note that the parameter to RETAIL/DEBUGREGISTERZONES MUST be NULL if you want to register debug zones from an application!

    If you are using precompiled headers you have to set DebugZones.cpp to "Not Using Precompiled Headers" (in VS2008 right click DebugZones.cpp in your solution, click "Properties", then select "Precompiled Headers" under "Configuration Properties -> C/C++" and change the "Create/Use Precompiled Header" value). Now include "DebugZones.h" in any file you want to use debug zone logging.

    The attached ZIP file contains the complete template.

    I hope this template will prove as useful to you as it is to us!

    Windows Embedded Compact May 2014 Update 35 breaks binary compatibility of Silverlight applications

    Warning to everybody using Silverlight: the May 2014 Update 35 for Windows Embedded Compact 7 breaks binary compatibility for Silverlight applications!

    You will have to regenerate your SDK and recompile your Silverlight applications, otherwise you will encounter a data abort exception in xamlruntime.dll:

    Exception 'Data Abort' (0x4): Thread-Id=05d5006e(pth=c0891b0c), Proc-Id=04680072(pprc=c089196c) 'vplayer.exe', VM-active=04680072(pprc=c089196c) 'vplayer.exe'
    PC=4017c64c(xamlruntime.dll+0x0002c64c) RA=40015b54(ceperf.dll+0x00005b54) SP=0007f91c, BVA=00000000

    The bigger problem is that all of the Silverlight applications shipped with WEC7 (video player, music player, photo viewer, etc) are shipped as pre-compiled executables and are not build on the spot. You will have to do a manual build of public\mediapps\oak\samples\cemp followed by a clean sysgen of your OS Design to get the photo viewer, video and music player to work again.

    Of course these executables should have been recompiled and included in update 35. Note that I only identified the media player applications, but there are of course many more control panel items and executables that need to be updated. I hope a next update will update all of the Silverlight dependent pre-compiled files in the WINCE tree!

    WARNING: You may be tempted to do a "Build and Sysgen" (blddemo without -q) to build the entire tree. Don't ever do this! It will leave your WINCE tree in a undetermined state. Read this to understand why. In fact you should remove the dangerous build commands from the Advanced Build menu. Read this to learn how.

    Follow these steps:

    1. Uninstall the SDK for your OS Design
    2. Update your WEC7 tree with the latest updates
    3. Open your OS Design
    4. In the Solution Explorer, browse to \public\mediaapps\oak\samples\cemp
    5. Right click cemp and choose "Rebuild (build -c)" from the context menu (do this for both a debug and retail build config!)
    6. Now select the root of your OS Design in the Solution Explorer
    7. And click "Clean Sysgen (blddemo clean -q)" from the Build->Advanced Build Commands menu (or Custom Build Commands menu if you followed these instructions)
    8. Build the SDK for the OS Design (make sure you built the dependent build configuration first)
    9. Close all Visual Studio instances
    10. Install your new SDK
    11. Recompile all of your Silverlight applications that were built against the previous SDK

    Repeat step 5 for any other Silverlight components that do not work anymore after applying Update 35 (May 2014).

    Standards vs Proprietary Modules

    At GuruCE we work with a variety of boards from various customers. Some customers create their own boards from scratch, some use proprietary modules and yet some others choose a standard like Q7. We have found that standards, like Q7, work well for standard and well defined processor architectures like x86, but not so much for processor architectures that support a wide variety of functions even between different CPUs of the same family (like the Freescale iMX CPU range).

    Martin Welford, CEO of our hardware partner Device Solutions has written a nice blog post about this and writes on the GuruCE blog as a guest writer:


    Choosing a SOM – Why Standards don’t work for ARM modules

    When choosing a System on Module (SoM) for a new project, you quickly find that there are some which follow a standard, and others which don’t. On the standards side, you may have heard of Q7 or SMARC. Proprietary modules use SO-DIMM connectors, board-to-board connectors or modules like our Topaz and Quartz products have no connector at all and solder directly to a board.

    This post explores some of the reasons why we at Device Solutions have gone the proprietary non-standard path, and why we think standards don’t work for ARM and don’t deliver on the benefits you expect from a standard.

    Why choose a standard?

    For processor modules, having a second or third supply option sounds attractive. Obsolescence is a big problem and using a standard module to avoid this sounds like a compelling reason to go down that road. In fact it does work very well – for x86 based modules. However x86 chips are very well defined compared to the huge variation in features found on ARM based parts.

    Why standards don’t work for ARM

    ARM devices are used for a huge variety of applications, with an equally diverse set of requirements. If you have ever taken a close look at a Freescale i.MX part, you will see a lot of different functions and no single application makes use of them all.

    This creates some big problems when trying to map an ARM chip to a standard interface. The challenges are:

    • Wide range of features, and not enough pins to expose them all.
    • Multiplexed features – which feature do you pick for a particular pin?
    • Functions change between chip generations and there may be no slot on the standard interface for a new feature. A good example of this is display interfaces – these have evolved from parallel TFT and chips have this interfaces along with LVDS, VGA or HDMI and now MIPI.

    Designing with a standard ARM module

    All this is not to say that ARM modules based on a standard don’t work at all. They do, but they might not do everything you expect (or need) them to do.
    The first thing to check is, can you access all the features on the chip that you need? Make sure anything you think you might need is available. It is painful to get half-way through a design only to find you can’t get at a vital signal!

    Using a standard module for second source reasons

    This is where things get tricky and your design effort may effectively double. Because of all the reasons above, you can’t rely on two different standard ARM modules to give you exactly the same signals on the interface. It is important to identify what module you are going to use as a second source at the design stage. Every signal will need to be analysed and your base-board may need to have different build options for each module to get it working. Often this proves to be impossible because some vendors don’t share module schematics.

    An alternative to second souring

    Often the reason for having a second source is continuity of supply. Rather than invest in extra engineering (which is expensive and time consuming enough!), we suggest you ask the module vendor if they have an escrow service for their design files. This way should there be a problem for whatever reason, you will still have access to the module.

    Conclusions

    If you have made it this far, you will see that there are some issues with the current ARM based modules that follow a standard. Our advice is to choose a module that is the best fit for your design, and to solve second sourcing issues by other means.
    There are a lot more details we haven’t gone into around this issue.

    Contact us if you would like to know more.

    Martin Welford
    Device Solutions

    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.

    Pages

    Subscribe to RSS - blogs


    Main menu 2

    by Dr. Radut