After installation of the porting kit I was looking for some information about the toolchain to use. The only hint I could find in the documentation is that GCC4.2 or later is supported for the ARM architecture. Frivolous as I am, I installed the first GNU ARM toolchain for Windows I found on the web. A few seconds later the build script ran and a lot of red output was flashing in the build window. Usually I like the red color but not in this case! ERRORS - wherever you look! Sure.. GCC support. Fortunately the cause was obvious. The toolchain I'd installed doesn't include a none EABI compiler, that was called by the build script. Due to the lack of information, I had to try several toolchains until I found the free ARM Tools from Raisonance, which finally worked :)
These are the three easy steps to build your home-made firmware:
- Start a command window
- Call setenv_gcc.cmd in the installation directory of the porting kit with the path of your toolchain to set up your build environment
setenv_gcc.cmd C:\PROGRA~1\RAISON~1\Ride\arm-gcc - Invoke MSBuild.exe with the command below in the directory of your platform solution
msbuild dotNetMF.proj
E Voilá. We have built a release version of the .NET Micro Framework V3.0 firmware ready for flashing. How to do this? Take a look at this previous post :)
The following is just a reminder of the used OpenOCD commands for me, if I want to flash my i.MXS board again ;)
flash probe 0
flash erase 0 0 63
flash write_binary 0 C:\MicroFrameworkPK_v3_0\BuildOutput\ARM\GCC4.2\FLASH\release\iMXS\bin\TinyBooterDecompressor.bin 0x0
flash write_binary 0 C:\MicroFrameworkPK_v3_0\BuildOutput\ARM\GCC4.2\FLASH\release\iMXS\bin\tinyclr.bin\ER_CONFIG 0x40000
flash write_binary 0 C:\MicroFrameworkPK_v3_0\BuildOutput\ARM\GCC4.2\FLASH\release\iMXS\bin\tinyclr.bin\ER_FLASH 0x60000
flash write_binary 0 C:\MicroFrameworkPK_v3_0\BuildOutput\ARM\GCC4.2\FLASH\release\iMXS\bin\tinyclr.bin\ER_DAT 0x120000
The result looks like this:
Even the output of the deployment tool tells us V3.0. Now we could use Visual Studio to develop and deploy our real application with all the features of the new SDK.
Next time we'll visit the wonderful world of the gdb console and try to debug the whole thing. No, just kidding - we'll use a debugger with a graphical interface of course :)
Stay tuned!
5 comments:
Thanks for the update on using GCC. There isn't exactly a ton of information on the PK out there, and I'm not expecting that Microsoft will go out of their way to support GCC, so everything is a welcome addition. :-)
I've been using GCC with C/ARM for a while, and while I agree Keil or IAR's compilers may be a bit more efficient, free is good, and there are a lot of people that use GCC on the internet (in the lpc2000 yahoo group, for example). As such, I'd love to be able to stick with GCC, and not just for financial reasons, but am having some problems getting the toolchain you mentionned to work with the PK.
Despite the fact that all the files exists, GCC always spits out:
Could Not Find E:\MicroFrameworkPK_v3_0\BuildOutput\ARM\GCC4.2\FLASH\release\OlimexH2294\lib\LPC22XX_TIME.lib
or ...LPC22X_TIME.lib.manifest, etc.
It's the same for any .lib file. The files are generated and I don't get why the linker (I presume) is throwing out these errors. Perhaps it is a simple issue configuring the toolchain, but where should I be setting the particular permissions, etc.? If you have any idea, I'd appreciate it, since I'm sure other people will have the same issue (I'm starting from clean installs of both the PK 3.0 and Raissonance's RKit-ARM_BN29).
In any case, thanks for the link and pointing me towards a presumably compatible pre-compiled toolchain.
Kevin.
For reference sake, I asked what Microsoft is using internally as a GCC toolchain and apparently it's Code Sourceries freely available G++ Lite ARM toolchain. I used an older version (Q3 2007), since the newer release use GCC 4.3, and the PK is made to work with 4.2. It can freely be downloaded here:
http://www.codesourcery.com/gnu_toolchains/arm/portal/release316
Kevin.
Kevin,
I do not have an immediate solution to your GCC problem but it could be useful if you can use msbuld with the '/v:diag' option to get some more diagnostic messages while executing the build. Also make sure that your environment does not have any FLAVOR_MEMORY or FLAVOR_ARM environment variables set and that you execute the build with the following command from the root of the PK (%SPOCLIENT%):
'msbuild /p:platform=iMXS /p:flavor=debug /p:Memory=flash dotNetMF.proj'
This will not likely solve your problem but could help you find it.
Lorenzo
Where did you get these offsets for the flash fragments (TinyBooterDecompressor, ER_CONFIG, ER_FLASH, ER_DATA) from?
I cannot find any corresponding values in the scatter file. :(
When building my own image with different addresses and sizes, the filesizes cannot be taken as simple hint. In case of using the bootloader's filesize as offset for config, it tells me that it cannot write to this address. But writing e.g. at 0x40000 as you do works. Very strange, enlight me please :)
Post a Comment