Error copying OpenNETCF files during Sysgen or BSP Build

Dec 17, 2008 at 5:29 AM
Great BSP!  Seems to have a very good set of supporting features and tools and I am looking forward to working with it.

I was able to Sysgen and get a custom image I was creating downloaded to my board but was having problems with several lines similar to this;

'C:\WINCE600\OSDesigns\GumstixIII_BIN_1\GumstixIII_BIN_1\RelDir\GumstixIII_BIN_ARMV4I_Release>copy' /Y OpenNETCF.Configuration.dll ..\..\SDKs\Managed

These would result in an error because it could not find the OpenNETCF Smart Device Framework source files, OpenNETCF.Configuration.dll in this case.

After some investiation, I found a postlink.bat file in the Subproject GumstixManagedAPI that was supposed to copy these from the SDF folder into the target release folder.  I could not get this postlink.bat file to execute after the project built then it dawned on me that this is a CSharp project and this may be because it does not have the same kind of linking phase as C++.

I got through the build by copying the files from the SDF folder into the release folder and I can now build.

Is this correct? ... or do I possibly have a configuration problem with my platform builder that is keeping the postlink.bat file from executing?

Thanks

-Mike
Dec 17, 2008 at 7:24 AM
Interesting, is it failing on the copy or actually building the API?
There is some C# compiling and linking involved.
If I had to guess it might be you do not have the full C# support installed with your Visual Studio 2005??
Maybe a managed CLR version problem?? Look at SOURCES file.

You can always remove the API from your solution by unselecting it from the catalog.
You can also build the API separately as a standalone VS project as a test. The csprj file is in the ..\VSProjects\GumstixManagedAPI directory.

DV 
Dec 19, 2008 at 6:42 AM
API builds fine but the postlink.bat for the GumstixManagedAPI never executes.  It was actually kind of strange, I was not even trying to use these API's just yet but I was getting errors stating that it was expecting and ENDIF in the file platform.bib.  However, upon inspection I could not find any missing ENDIF's for IF or ; @CESYSGEN IF statements in platform.bib.  I went to view the output in the file makeimage.out and the only errors I found were failure to find the source file for the set of around 8 copy commands for the OpenNETCF stuff (see above).  These files were no where to be found in the release directory "C:\WINCE600\OSDesigns\GumstixIII_BIN_1\GumstixIII_BIN_1\RelDir\GumstixIII_BIN_ARMV4I_Release".  I could find them in the SDF folder located at "C:\WINCE600\PLATFORM\GumstixIII_BIN\VSProjects\SDF" and so I copied them from this location manually to the RelDir location and the error about the ENDIF disappeared.

After some investigation, I found the postlink.bat file in the GumstixManagedAPI subproject that was setup to copy these automatically from the SDF folder to the RelDir folder above.  However, I could not see any evidence that postlink.bat was ever executed, I even tried Clean sysgen, rebuild bsp and subprojects and rebuild GUMSTIXIII_BIN_1 commands from the build menu in VS / Platform builder, still did not execute postlink.bat.  What is strange is that I would have expected the output of all the subprojects (autolaunch, GumstixManagedAPI, GumstixManagedInfo, etc to deploy with the nk.bin into the \windows folder but they do not appear to be present on my image once I download it even though they are in the RelDir output folder.

The manual copy gets me building but something does not seem right here.

-Mike
Dec 19, 2008 at 1:26 PM
Sounds like you are on the trail. I would also try building the default OSDesign (GumstixIII_BIN_1) clean with no modifications and see if it completes.
Might yeald some clues. Also you might try, if you have not already, just execute the postlink.bat file from PB's command dos window and see if everything copies correctly.

DV. 
Dec 21, 2008 at 1:41 AM
Deleted everything (i.e. Gumstix OSDesigns and Gumstix Platform folders), recopied source for binary BSP and tryed the Build GumstixIII_BIN_1 and still no go.  However after this, I could then right click on the individual sub-projects and choose build from their context menu, then I came back and did Build GumstixIII_BIN_1 again and it worked.

I did not try Build BSP and Subprojects first, I wonder if that command would have worked if I had done it first.  I may try this later and post back.

The process right now seems to be;

* Take the menu option "Build GumstixIII_BIN_1" from the Build menu (you will get error)
* Build all subprojects from the right click context menu (specifically GumstixManagedAPI seems the be the critical one) (should succeed)
* Again take the menu option "Build GumstixIII_BIN_1". (build should succeed)

The other thing I am finding out is that the subproject .reg and .bib files don't seem to be evaluated during the build and thus the subprojects are not included into the nk.bin.  I took the commands from the .bib and the .reg files and included into project.bib and project.reg as appropriate and they are deployed onto the target.  Is this supposed to be the case or should the individual subprojects .bib, .reg, etc be evaluated when doing Build, Sysgen, etc?

I also noticed something else strange and maybe you can tell me if this is normal or not. In the CE Catalog Items View, I follow this branch "Third Party/BSP/GumstixII_BIN PXA270 Platform: ARMV4I/API" and all the subprojects (including GumstixManagedAPI) are listed there and have an red "X" on them instead of a green check mark.  I right click on one of them and I get the menu option that read "Reasons for Exclusion of item".  I take this menu option and it just shows an empty list box where the reaons should be.

-Mike
Dec 21, 2008 at 2:59 AM
I always do the "Build->advanced build commands->sysgen"
From then on I just use the "Build->advanced build commands->Build BSP and subprojects" if I just modify something in the BSP.
You have to do a sysgen if you add or remove a MS component.

The red X's are normal. There is some kind of weird dependency that does this. It is harmless.

DV