Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Firmware build issues


  • Please log in to reply
36 replies to this topic

#1 jeremy

jeremy

    Member

  • Members
  • PipPip
  • 23 posts

Posted 11 August 2010 - 03:32 AM

So, I'm trying to build the firmware for the Netduino using GCC. As expected the firmware is pretty large. When I remove some features the Metadataprocessor.exe task fails with the error CLR_E_FAIL. In fact, it fails with this error for many different conditions which makes the error utterly useless. Never mind. This is why we have the source and debuggers. Anyway, that aside, it also fails with trying to sign a file of zero bytes long. In this case it is the file D:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.bin\ER_DAT. While I can fix the Metadataprocessor code to not try to sign a zero byte file which does have a zen feel about it now I thing about it. I am more wondering if the ER_DAT file should actually be zero length? Jeremy.

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 11 August 2010 - 04:34 AM

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

#3 jeremy

jeremy

    Member

  • Members
  • PipPip
  • 23 posts

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 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 11 August 2010 - 01: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.

#5 jeremy

jeremy

    Member

  • Members
  • PipPip
  • 23 posts

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 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

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 jeremy

jeremy

    Member

  • Members
  • PipPip
  • 23 posts

Posted 11 August 2010 - 03:55 PM

As an update, using a clean machine with just GCC 4.2, VS2010 and the porting kit I can now compile without any wierdness. My previous dev environment is obviously trashed. It happens. To build the firmware as shipped I needed to increase the available size for the code by moving the deployment base address up to 0x00175B60. I haven't yet down the firmware upload to the device.

#8 jeremy

jeremy

    Member

  • Members
  • PipPip
  • 23 posts

Posted 11 August 2010 - 04:03 PM

And now for the dumb question of the day. 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? :huh:

#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

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 jeremy

jeremy

    Member

  • Members
  • PipPip
  • 23 posts

Posted 11 August 2010 - 04:50 PM

More interesting behaviors. I re-installed the crypto pack and some of the weirdness is back. Turns out if an attempt is made to sign a zero length file with the crypto pack installed Metadataprocessor will barf. The issue is in HRESULT Cmd_SignFile( CLR_RT_ParseOptions::ParameterList* params = NULL ) at line 1570ish: TINYCLR_CHECK_HRESULT(CLR_RT_FileStore::LoadFile( dataFile.c_str(), buf )); if(!SignData( &buf[0], buf.size(), privateKey, &signature[0], signature.size() )) buf.size() barfs because some internal pointers are null. The LoadFile call does not load anything into buf because in this case ER_DAT is zero length. buf is declared as follows: CLR_RT_Buffer buf; CLR_RT_Buffer is a typedef somewhere along the line to a std::vector. Changing the definition to actually allocate some memory clears the problem up: CLR_RT_Buffer buf(RSA_BLOCK_SIZE_BYTES); One thing I'm not sure of is if any signing is done if the crypto pack is not installed. It does not appear so since no .sig files are generated if the crypto pack is not installed. Any hints would be helpful here. Jeremy

#11 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 11 August 2010 - 09:40 PM

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.

Thank you for the information. However, on my dev. machine the above steps result in the following MSBuild error when building NativeSample.proj:
'"\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 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 11 August 2010 - 09:53 PM

Curious. We'll do a clean build and play with both RVDS and GCC compilation to see if we can help make it easier...

#13 Dave

Dave

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationRock Hill, SC

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 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

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 Dave

Dave

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationRock Hill, SC

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 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 16 August 2010 - 12:44 PM

The tinyclr firmware was about 15K larger than the RVDS code as best I can tell.

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

#17 jeremy

jeremy

    Member

  • Members
  • PipPip
  • 23 posts

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 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 17 August 2010 - 08:22 AM

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.

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

#19 CMD

CMD

    New Member

  • Members
  • Pip
  • 5 posts

Posted 17 August 2010 - 12:56 PM

Compile firmware failed. "c:\MicroFrameworkPK_v4_1\Solutions\Netduino\dotnetmf.proj" (default target) (1 ) -> "c:\MicroFrameworkPK_v4_1\Solutions\Netduino\NativeSample\NativeSample.proj" (B uild target) (2) -> "c:\MicroFrameworkPK_v4_1\devicecode\pal\TinyCRT\dotNetMF.proj" (Build target) (48) -> "c:\MicroFrameworkPK_v4_1\devicecode\pal\TinyCRT\dotNetMF_loader.proj" (Build t arget) (50) -> (ArmCompileCPP target) -> c:\MicroFrameworkPK_v4_1\tools\targets\Microsoft.SPOT.System.GCC.targets(274, 5): error MSB3073: The command " "d:\yagarto\bin\arm-none-eabi-gcc.exe" -xc++ - Wno-invalid-offsetof -fcheck-new -ffunction-sections -mlong-calls -fomit-fram e-pointer -fdollars-in-identifiers -fshort-wchar -fno-exceptions -funsigned-ch ar -mstructure-size-boundary=8 -DHAL_REDUCESIZE -DTINYCLR_ENABLE_SOURCELEVELDE BUGGING -mthumb-interwork -DCOMPILE_THUMB -mthumb -DVERSION_MAJOR=4 -DVERSIO N_MINOR=1 -DVERSION_BUILD=2821 -DVERSION_REVISION=0 -DOEMSYSTEMINFOSTRING="\"Ne tduino by Secret Labs LLC\"" -DPLATFORM_ARM_AT91SAM7X -DPLATFORM_ARM_Netduino - DTARGETLOCATION_FLASH -DLITTLE_ENDIAN -DGCC_V4_2 -DPLATFORM_DEPENDENT_HEAP_SIZ E_THRESHOLD=10240 -DPLATFORM_DEPENDENT_HEAP_SIZE_THRESHOLD_UPPER=15360 -mfloa t-abi=soft -mcpu=arm7tdmi -mlittle-endian -Os -DNDEBUG -fno-default-inline -Ic:\MicroFrameworkPK_v4_1\DeviceCode\pal\tinycrt\reducesize -Ic:\MicroFramewor kPK_v4_1\DeviceCode\include -Ic:\MicroFrameworkPK_v4_1\DeviceCode\Cores\arm -Ic :\MicroFrameworkPK_v4_1\Support\Include -Ic:\MicroFrameworkPK_v4_1\crypto\inc -Ic:\MicroFrameworkPK_v4_1\CLR\Include -Ic:\MicroFrameworkPK_v4_1\CLR\Librari es\CorLib -Ic:\MicroFrameworkPK_v4_1\CLR\Libraries\SPOT -Ic:\MicroFrameworkPK_v 4_1\CLR\Libraries\SPOT_Hardware -Ic:\MicroFrameworkPK_v4_1\CLR\Libraries\SPOT_G raphics -Ic:\MicroFrameworkPK_v4_1\CLR\Libraries\SPOT_Net -Id:\yagarto\lib\gcc\ arm-none-eabi\\include -Ic:\MicroFrameworkPK_v4_1\Solutions\Netduino -Ic:\Micro FrameworkPK_v4_1\devicecode\Targets\Native\AT91 -Ic:\MicroFrameworkPK_v4_1\Devi ceCode\Cores\arm -Ic:\MicroFrameworkPK_v4_1\DeviceCode\Cores\arm\Include -Ic:\M icroFrameworkPK_v4_1\DeviceCode -Ic:\MicroFrameworkPK_v4_1\DeviceCode\Include - Ic:\MicroFrameworkPK_v4_1\CLR\Include -Ic:\MicroFrameworkPK_v4_1\DeviceCode\Tar gets\Native\AT91\Netduino -Ic:\MicroFrameworkPK_v4_1\Support\Include -Ic:\Micro FrameworkPK_v4_1\DeviceCode\include -Ic:\MicroFrameworkPK_v4_1\CLR\include -Ic: \MicroFrameworkPK_v4_1\Crypto\inc -Ic:\MicroFrameworkPK_v4_1\DeviceCode\include -o c:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netdu ino\obj\DeviceCode\pal\tinycrt\reducesize\tinycrt.obj -c c:\MicroFrameworkPK_v4 _1\devicecode\pal\TinyCRT\tinycrt.cpp " exited with code 1. [c:\MicroFramework PK_v4_1\devicecode\pal\TinyCRT\dotNetMF_loader.proj] 13 Warning(s) 1 Error(s) Use GCC 4.5.0, Windows 7, .Net MF PK with all libraries, VS 2010 Plz Help

#20 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

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

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.