Well, I’m pretty sure that it’s not actually running GCC. It should be something like “gcc-arm-none-eabi.exe -xc++…”
Oh, right then your setenv_base needs some fixing. What version of gcc do you use?
Edit: Also what is your setenv_gcc looks like and how do you run it (what parameters do you provide)?
Well, I did fix by setenv_base (by changing 4.6.0 to 4.6.1), but that didn’t solve the problem.
I just seemed to get further after I changed “GCC4.2” to “GCC4.6” on line 12 of Microsoft.Spot.system.gcc.targets.
Now I get things like:
[quote] In file included from W:\MicroFrameworkPK_v4_2_netduinogo\CLR\Core\HeapPersistence/…\Core.h:8:0,
from W:\MicroFrameworkPK_v4_2_netduinogo\CLR\Core\HeapPersistence\Heap_Persistence_stub.cpp:5:
W:\MicroFrameworkPK_v4_2_netduinogo\CLR\Include/TinyCLR_Runtime.h:3285:5: error: size of array ‘__CT_ASSERT__tinyclr’ is negative[/quote]
I called setenv_gcc4.6 d:\Utils-Code\path\to\codesourcery\lite
Hang on, scratch that, I was still trying to build the i.MXS solution. Small wonder it doesn’t work.
Now, with the NetduinoGo solution, I get all sorts of “target CPU does not support ARM mode” errors.
Which is true, it doesn’t.
I also notice that GCC is being told to target Cortex-M3 (which is wrong) and software FPU (whatever, that’ll get sorted).
@ godefroi if you are using NetduinoGoFirmware repository, please make sure you are building the latest version, either by downloading the ‘dev-gcc’ branch archive or updating to the repository ‘tip’ in you favorite Mercurial client. Also, if you don’t get ‘setting environment for Yagarto/Sourcery version 4.6.x’ when running setenv_gcc.cmd, it means you are using toolchain which is not being recognized.
@ CW2 I’m using simply the ZIP package from the Netduino site. I’ll give the repository version a shot.
As far as I remember this is how mine is setup:
-
use default setenv_gcc.cmd
-
Change setenv_base.cmd
IF "%COMPILER_TOOL_VERSION%"=="GCC4.2" (
set GNU_VERSION=4.6.1
set ARMINC=%ARG3%\lib\gcc\arm-none-eabi\%GNU_VERSION%\include
set ARMLIB=%ARG3%\lib\gcc\arm-none-eabi\%GNU_VERSION%
set GNU_TOOLS=%ARG3%
set GNU_TOOLS_BIN=%ARG3%\bin
set GNU_TARGET=arm-none-eabi
) ELSE (
Oh, that explains a lot. At this moment, the GCC support for Netduino Go! firmware is available in my NetduinoGoFirmware repository on BitBucket (https://bitbucket.org/CW2/netduinogofirmware), ‘tip’ in gcc-dev branch. It is based on the official Netduino Go! source (the zip archive from Netduino downloads section). Also, please check out the additional notes published on Netduino forum (Netduino Go firmware source for GCC - Beta Firmware and Drivers - Netduino Forums) and the repository Issues (https://bitbucket.org/CW2/netduinogofirmware/issues).
I have verified the solution compiles with the latest Sourcery 2011.09-69, but it has not been verified on the hardware yet. I have noticed certain differences in the generated code between Sourcery and Yagarto (my primary toolchain), so there could be some side-effects.
Additionally, there is one annoyance with the Yagarto I use (20111119): it comes with newlib that does not have support for 64-bit integers, so string formatting (s/printf) does not work properly for ‘long’ types. I had to compile a special newlib version, it will be available for download after some more testing.
Hope this helps.
It found my tools fine, it’s running the build now.
It apparently builds the Windows2 solution first (which is the emulator?).
Isn’t Yagarto being discontinued? I’m partial to it myself, simply because GHI recommends it for RLP, and because I’m not a huge fan of using free versions of commercial products, because they tend to disappear.
How is devkitARM? Is its newlib broken as well?
(and, now it’s done with the build. Thanks, CW2!)
devkitARM is supported in setenv_gcc.cmd, at this moment there are a few missing symbols during link phase - probably not hard to fix, but because of that there are not binaries to be tested on the hardware (yet). Unfortunately, it is very time consuming to perform builds and verification for all those different toolchains and resulting binaries, so I have to go one by one… I hope you understand.
(Just for clarification, the newlib is not ‘broken’ per se, it is just compiled with certain options - there is about zillion of them : )
No, I understand. I also appreciate greatly the work you’ve put into this, and that you continue to put into it. I don’t have plans to try devkitARM, I was just curious. When you’re volunteering your time, I think it’s entirely reasonable to pick a toolset and stick with it 
Also, thanks to Architect for the guidance as well
When I flashed a Cerb40 with the Netduino Go firmware compiled with RVDS for a 12MHz crystal, the device is unresponsive when plugged into the PC.
The only investigation I made was to determine that the DFU supplied by GHI for the Cerberus has a different section layout than that of the DFU for the Netduino.
I did flash the exact same DFU into a Discovery Board with the hardware mod as described on the Wiki and it does work fine on the Discovery.
I posted the firmware here:
I tried to assemble some instructions, but I may have missed some steps…
BUILDING FEZ Cerberus firmware with GCC
Note: This process does not produce functional firmware yet. (April 20, 2012)
[ol]Download Yargato GCC: YAGARTO - Browse /YAGARTO for Windows/20111119 at SourceForge.net
Install Yargato into C:\yargato
Download SDK 4.2 (RTM QFE1) and Porting Kit 4.2 (RTM QFE1): http://netmf.codeplex.com/releases/view/82448
Install SDK
Install Porting Kit into C:\NETMF_CERB
Unzip the CerbFirmware.zip file into the C:\NETMF_CERB folder, overwriting all conflicting files
Open command prompt as admin
Execute → cd C:\NETMF_CERB
Execute → setenv_gcc.cmd C:\yagarto
Execute → msbuild solutions\FEZ_Cerberus\dotnetmf.proj /p:flavor=release
Wait 4-10 minutes for build (if you see any red, you’ve had a build error)
** Firmware is compiled now.
Download DfuSe from here: Microcontrollers (MCU) and Microprocessors (MPU) - STMicroelectronics
Unzip/Install ST Tools
** We need to Merge the firmware binary files from the build into a DFU file for loading
Open ST Micro → DfuSe → DFU File Manager
Select “I want to Generate a DFU…”
Click “Multi BIN…”
Click the “…” button and select one of the binaries from: C:\NETMF_CERB\BuildOutput\THUMB2\GCC-Yagarto-4.6.2\le\FLASH\release\FEZ_Cerberus\bin\tinyclr.bin
Set the address that cooresponds to that file from the scatterfile: C:\NETMF_CERB\Solutions\FEZ_Cerberus\TinyCLR\scatterfile_tinyclr_gcc.xml
Click “Add to list” and repeat for other binaries in the folder. (see tinyclr.it)
Click OK, then Generate…
Take the resulting DFU file and flash it as you would normally (http://wiki.tinyclr.com/index.php?title=Firmware_Update_FEZ_Cerberus)
[/ol]
Note: the Cerb40 has a Loader pin that needs to be connected to 3.3VDC and rebooted to get into the Loader mode. Once in Loader mode, the wire can be removed.
The scatterfile in that zip is definitely no good because the values don’t match with the STM32_BlConfig.cpp.
Would it be simpler to take the startup code and scatterfile from the netduino, and work from there? I can confirm that it compiles cleanly (haven’t tried loading it, yet) with GCC.
Ok, I fixed the scatterfile (I think) and changed a file in the tools folder to generate the ER_BOOT.bin file, but it’s still not working, although now it detects an unknown USB device… not sure if that is really progress :
Anyway, I updated the necessary files and zipped them up. Just unzip into your Porting Kit source folder as usual (or follow the instructions in the included richtext file, now with a screenshot of the dfu creation). Zip is located here (with Apr22 in the name):
here is some new info:
http://www.tinyclr.com/forum/topic?id=7738&page=1#msg76998