Firmware build issues
#1
Posted 11 August 2010 - 03:32 AM
#2
Posted 11 August 2010 - 04:34 AM
#3
Posted 11 August 2010 - 12:19 PM
Your two output files should be ER_CONFIG and ER_FLASH for the .NET Micro Framework runtime (TinyCLR) and TinyBooterDecompressor.bin for the bootloader (TinyBooter).
ER_CONFIG = Configuration Sector
ER_FLASH = .NET MF CLR
When you compile the unmodified Netduino firmware using GCC, do you still have troubles?
And just to verify, are you issuing the following command to compile?
C:\MicroFrameworkPK_v4_1\> msbuild Solutions\Netduino\dotnetmf.proj /p:flavor=release
Chris
Do you ever actually sleep?
That is the build command I'm using.
The stock firmware compiles fine sometimes and not others. The same goes for some of the other stock firmwares in the PK. I have noticed some other strange issues with the build. The metadataprocessor sometimes decides to build itself against the crypto stubs instead of the actual libs. I'm rolling back the image (I use vmware workstation) and will re-build the dev environment.
I have a list of gotchas for using GCC that I will post when I have sucessfully built and updated the firmware without bricking the netduino.
#4
Posted 11 August 2010 - 01:19 PM
#5
Posted 11 August 2010 - 02:19 PM
I have been able to successfully build v4.1.0 firmware using RVDS 4.1 Pro Evaluation, with only two minor changes (passing correct path to ADS_TOOLS_BIN MSBuild property via command line and copying platform_selector.h into DeviceCode\Initialization directory - it may require another 'proper' solution, but those were the simplest workarounds). Personally, I consider this a great result, given my experience with other embedded toolchains. I have not yet got the hardware though, so I could not verify it actually works.
I am going to try GCC, I am curious how it goes and what are size/code generation differences between those two compilers. Any hints, gotchas etc. would be appreciated.
The latest version of GCC is 4.4.x. The porting kit is tested against GCC 4.2.x. The lateset version of GCC has some compile errors due to casts. These could probably be fixed easily enough, but I went down to GCC 4.2. MS use CodeSourcery lite for testing, so I got the arm-2007q3-53-arm-none-eabi install from http://www.codesourc...bscription3053.
The tinyclr firmware was about 15K larger than the RVDS code as best I can tell.
I'm still trying to solve assorted build issues. I think the issue is I have a multitude of different dev studio versions, SDKs and GCC versions on the dev machine. I'm setting up a clean VM with just VS2010 and GCC and the porting kit to remove potential conflicts.
Metadataprocessor.exe is giving me fits for no apparent reason.
#6
Posted 11 August 2010 - 03:18 PM
I have been able to successfully build v4.1.0 firmware using RVDS 4.1 Pro Evaluation, with only two minor changes (passing correct path to ADS_TOOLS_BIN MSBuild property via command line and copying platform_selector.h into DeviceCode\Initialization directory - it may require another 'proper' solution, but those were the simplest workarounds). Personally, I consider this a great result, given my experience with other embedded toolchains. I have not yet got the hardware though, so I could not verify it actually works.
You should be able to compile without any additional changes. You do need to set up the environment variables beforehand, though. Here are step-by-step instructions on how to compile with RVDS:
*** Open a command-line prompt (CMD.EXE) <-- no need for Administrator privileges ***
C:\...> cd \MicroFrameworkPK_v4_1
C:\MicroFrameworkPK_v4_1> setenv_RVDS4.0.cmd "c:\program files\arm"
C:\MicroFrameworkPK_v4_1> msbuild Solutions\Netduino\dotnetmf.proj /p:flavor=release
If that doesn't work for you, unedited, please post the steps you're needing to take...and we'll do a clean install and compare here.
I am going to try GCC, I am curious how it goes and what are size/code generation differences between those two compilers. Any hints, gotchas etc. would be appreciated.
We have tested on GCC (important to use the CodeSourcery version) and the one difference we've found is the increased size of TinyBooter (bootloader) and TinyCLR (.NET MF runtime). Here are the three things to keep in mind when using GCC:
1. Use the GCC which comes with the version of CodeSourcery specified in the .NET MF release notes.
2. Build the "release" build. If you build "debug" builds, you'll have to edit the flash layout to dedicate more of your C# codespace to the .NET runtime. There are special conditionals which adjust the flash layout when using GCC automatically.
3. Erase your Netduino completely, flash the GCC-compiled TinyBooter using SAM-BA, and then deploy the GCC-compiled TinyCLR via MFDeploy. We've exposed an "erase pad" directly underneath D0 on the Netduino. To erase your Netduino, plug a jumper wire into the 3V3 or 5V power header and touch the "erase pad" for 220ms+ (and then disconnect all power from your Netduino to give it a full reset). Be very careful not to touch any other leads with the 5V/3V3 power
Chris
#7
Posted 11 August 2010 - 03:55 PM
#8
Posted 11 August 2010 - 04:03 PM
#9
Posted 11 August 2010 - 04:44 PM
Do I deploy the files in C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.bin or C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.hex?
tinyclr.hex
There are no dumb questions here. Just new things to learn and explore.
#10
Posted 11 August 2010 - 04:50 PM
#11
Posted 11 August 2010 - 09:40 PM
Thank you for the information. However, on my dev. machine the above steps result in the following MSBuild error when building NativeSample.proj:You should be able to compile without any additional changes. You do need to set up the environment variables beforehand, though. Here are step-by-step instructions on how to compile with RVDS:
*** Open a command-line prompt (CMD.EXE) <-- no need for Administrator privileges ***
C:\...> cd \MicroFrameworkPK_v4_1
C:\MicroFrameworkPK_v4_1> setenv_RVDS4.0.cmd "c:\program files\arm"
C:\MicroFrameworkPK_v4_1> msbuild Solutions\Netduino\dotnetmf.proj /p:flavor=release
If that doesn't work for you, unedited, please post the steps you're needing to take...and we'll do a clean install and compare here.
'"\armcc.exe"' is not recognized as an internal or external command
Passing ADS_TOOLS_BIN value via command line fixes it:
msbuild Solutions\Netduino\dotnetmf.proj /p:flavor=release /p:ADS_TOOLS_BIN="C:\Program Files\ARM\RVCT\Programs\4.1\462\win_32-pentium"
Then compilation of C:\MicroFrameworkPK_v4_1\Crypto\stubs\stubs.cpp fails
"C:\MicroFrameworkPK_v4_1\DeviceCode\include\..\Initialization\MasterConfig.h", line 12: Error: #5: cannot open source input file "platform_selector.h": No such file or directory #include <platform_selector.h>
After copying Solutions\Netduino\platform_selector.h into C:\MicroFrameworkPK_v4_1\DeviceCode\Initialization and changing #include <platform_selector.h> to #include "platform_selector.h" in MasterConfig.h the build succeeds.
Environment (installed in this order, default directories): Windows XP Professional SP3 English, Visual Studio 2010 Ultimate Trial (only C++ and C# options checked), .NET Micro Framework 4.1 SDK (4.1.2821.0), .NET Micro Framework 4.1 Porting Kit, Netduino 4.1 SDK 32-bit, Netduino 4.1.0 Firmware Source, RVDS 4.1 Pro Eval, .NET Micro Framework 3.5 SP1.
Note: MetaDataProcessor does not run properly on a computer where only .NET Framework 4.0 is installed, it fails with error 0x80131700. The solution is to install previous version of the Framework (e.g. 3.5 SP1) or it may be possible to specify some runtime settings in the app.config file - I have not had a chance to try that yet.
#12
Posted 11 August 2010 - 09:53 PM
#13
Posted 12 August 2010 - 03:48 AM
3. Erase your Netduino completely, flash the GCC-compiled TinyBooter using SAM-BA, and then deploy the GCC-compiled TinyCLR via MFDeploy. We've exposed an "erase pad" directly underneath D0 on the Netduino. To erase your Netduino, plug a jumper wire into the 3V3 or 5V power header and touch the "erase pad" for 220ms+ (and then disconnect all power from your Netduino to give it a full reset). Be very careful not to touch any other leads with the 5V/3V3 power
Chris
Is there any special USB driver you need to use SAM-BA? It doesn't see the board.
--Dave
#14
Posted 12 August 2010 - 04:43 AM
Is there any special USB driver you need to use SAM-BA? It doesn't see the board.
It's standard CDC, but Windows will need you to point it to the INF file. It's in the Atmel "program files" directory.
If you're running 64-bit Windows, you'll need to start your computer with driver signing disabled. Or on Windows 7 64-bit, run Windows XP Mode and use SAM-BA there (which is what I do on my computer--it works nicely).
Does that get you pointed in the right direction?
Chris
#15
Posted 12 August 2010 - 06:34 PM
It's standard CDC, but Windows will need you to point it to the INF file. It's in the Atmel "program files" directory.
If you're running 64-bit Windows, you'll need to start your computer with driver signing disabled. Or on Windows 7 64-bit, run Windows XP Mode and use SAM-BA there (which is what I do on my computer--it works nicely).
Does that get you pointed in the right direction?
Chris
Windows 7 XP Mode, is a virtual running XP. It has access to the hosts hardware? Didn't know that. I'll give it a try.
Thanks,
--Dave
#16
Posted 16 August 2010 - 12:44 PM
CodeSourcery G++ Lite 2008Q1-126 produces firmware about 8 KB larger than RVDS and is the last one that does not require any code modifications. GCC 4.4 has changed va_list type mangling, so it probably requires more complex changes, which are not worth it for me to do now - perhaps .NET Micro Framework team at Microsoft will support it in future release.The tinyclr firmware was about 15K larger than the RVDS code as best I can tell.
Interestingly, removing 'File System' feature in Solution Wizard gains only about 0.5 KB, it seems that more significant code size reduction should be achieved by excluding System.IO.dll managed library, which is about 13 KB. But this is probably good idea only for private/test builds - I'll try to do it in one of my future experiments...
#17
Posted 16 August 2010 - 10:57 PM
CodeSourcery G++ Lite 2008Q1-126 produces firmware about 8 KB larger than RVDS and is the last one that does not require any code modifications. GCC 4.4 has changed va_list type mangling, so it probably requires more complex changes, which are not worth it for me to do now - perhaps .NET Micro Framework team at Microsoft will support it in future release.
Interestingly, removing 'File System' feature in Solution Wizard gains only about 0.5 KB, it seems that more significant code size reduction should be achieved by excluding System.IO.dll managed library, which is about 13 KB. But this is probably good idea only for private/test builds - I'll try to do it in one of my future experiments...
I'm working on changing the build scripts to allow using GCC4.2 or GCC4.4. The changes for va_list type mangling are fairly trivial, but I want to be able to build with either the GCC compiler tested by the porting team or the latest 4.4. Since I have to do this in my spare time it may be a couple of days...
#18
Posted 17 August 2010 - 08:22 AM
So, this means you plan to create a copy of setenv_gcc.cmd for 4.4 (?). I have managed to successfully build the firmware with GCC 4.4.1 (CodeSourcery G++ Lite 2010Q1) with only two changes: I commented out hal_vsnprintf() function in tinycrt.cpp (lines 360-365) and copied libraries from lib\gcc\arm-none-eabi\4.4.1 to 4.2.1 - this can be easily fixed in setenv_base.cmd (e.g. by adding a new case for "GCC4.4"). The result binary is only 704 bytes bigger (4.1.0.2, default features).I'm working on changing the build scripts to allow using GCC4.2 or GCC4.4. The changes for va_list type mangling are fairly trivial, but I want to be able to build with either the GCC compiler tested by the porting team or the latest 4.4.
#19
Posted 17 August 2010 - 12:56 PM
#20
Posted 17 August 2010 - 03:11 PM
Compile firmware failed.
Use GCC 4.5.0, Windows 7, .Net MF PK with all libraries, VS 2010
Plz Help
Hi CMD, welcome to the community forums!
Please use the following GCC compiler version:
http://www.codesourc...rtal/release316
Some of our community members are working on tweaks to support other versions of GCC (see above posts in this thread for mroe details).
Chris
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users