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.
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).
Pretty much, other than setting the GCC versions properly so you don't have to copy libraries about. Most of the changes are only in a couple of key build files. The change to call set base with GCC4.4 instead of GCC4.2 has a bunch of side effects that cause the build to fail without matching changes elsewhere.
I'm also making the scatterfiles dependent on the version of GCC so you can switch back and forth easily. So instead of scatter_file_gcc there is scatter_file_gcc4.2 and scatterfile_gcc4.4. The build output directories also properly reflect the version of GCC used, 4.2 or 4.4.
I'll need to annotate the build files to make the changes stand out so other folks know what I changed.
I did pretty much the same thing as you the first time through.
Thanks Chris, but after installing gcc, which you recommended, the number of errors increased to 4.
List attached
New case with other projects (SAM7X and SAM7S) the number of errors decreased to the same four
Will any suggestions?)
Complete cleaning helped.
All compile, but at the end following problem:
d: \ Sourcery \ bin \ arm-none-eabi-ld.exe: c: \ MicroFrameworkPK_v4_1 \ BuildOutput \ TH
UMB \ GCC4.2 \ le \ FLASH \ release \ Netduino \ bin \ tinyclr.axf section ER_FLASH will no
t fit in region LR_FLASH
d: \ Sourcery \ bin \ arm-none-eabi-ld.exe: region LR_FLASH overflowed by 15,080 byt
es
This is because the firmware is larger than necessary, or for some other reason?
Complete cleaning helped.
All compile, but at the end following problem:
d: \ Sourcery \ bin \ arm-none-eabi-ld.exe: c: \ MicroFrameworkPK_v4_1 \ BuildOutput \ TH
UMB \ GCC4.2 \ le \ FLASH \ release \ Netduino \ bin \ tinyclr.axf section ER_FLASH will no
t fit in region LR_FLASH
d: \ Sourcery \ bin \ arm-none-eabi-ld.exe: region LR_FLASH overflowed by 15,080 byt
es
This is because the firmware is larger than necessary, or for some other reason?
CMD,
you need to spend some time reading and understanding the porting kit documentation. This will explain your issue. Look up scatterfiles.
The fact is that there is no compelling reason to build the firmware unless you want to make changes to it. If you want to make changes then there is no alternative but to spend a good few hours understanding what the porting kit docs have to say.
This assumes you have a background doing embedded development in assembler and/or C and understand how to lay out memory. The tinyCLR firmware is not place to start learning about embedded development in C.
you need to spend some time reading and understanding the porting kit documentation. This will explain your issue. Look up scatterfiles.
The fact is that there is no compelling reason to build the firmware unless you want to make changes to it. If you want to make changes then there is no alternative but to spend a good few hours understanding what the porting kit docs have to say.
This assumes you have a background doing embedded development in assembler and/or C and understand how to lay out memory. The tinyCLR firmware is not place to start learning about embedded development in C.
Hello,
I also try to rebuild firmware with GCC 4.2, and after multiple issues, I'm finaly near the success (I hope). I just have a issue regarding signature. But it's strange because I thought I do not need to sign firmware.
I also try to rebuild firmware with GCC 4.2, and after multiple issues, I'm finaly near the success (I hope). I just have a issue regarding signature. But it's strange because I thought I do not need to sign firmware.
Next time, I will read the thread more carefully ... The answer was in the thread.
Now I will start to try some native code,
Pascal
Next step, deploying failed,
Reflash with SAM-BA, first with my own TinyBooterDecompressor compiled with GCC, then failed,
Reflash with official TinyBooterDecompressor, success,
But now, I'm not able to start any native code
Here is what I have done :
- Install PK 4.1
- Install Network part
- Install Crypto part
- Install CodeSourcery 4.2 (lite)
- Open cmd
- setenv_gcc_cmd C:\PROGRA~1\CODESO~1\SOURCE~1 (using 8.3 name, long name doesn't work)
- msbuild Solutions\Netduino\dotnetmf.proj /p:flavor=Release
- No enough room on flash
- Open Solutions\Netduino\TinyCLR\Scatter_tinyclr_gcc.xml
- Change Deploy_BaseAddress from 0x00172000 to 0x00175D28 to leave more space (exactly the difference showed by msbuild)
- Compile again
- Error during signature make
- Apply jemery fix
- compile again, then success (with a erase of BuildOutput folder and msbuild with /t:CleanBuild)
- msdeploy, failed
- reflash my arduino
- setenv_gcc_cmd C:\PROGRA~1\CODESO~1\SOURCE~1 (using 8.3 name, long name doesn't work)
I always copy and paste the gcc c++ compiler to "c:\gcc" after installing CodeSourcery. That also alleviates any issues with really long command line statements...
- No enough room on flash
- Open Solutions\Netduino\TinyCLR\Scatter_tinyclr_gcc.xml
- Change Deploy_BaseAddress from 0x00172000 to 0x00175D28 to leave more space (exactly the difference showed by msbuild)
I don't think you need to do this (although someone might correct me here)... Any changes to the flash layout using the older GCC compiler should probably be done in:
C:\MicroFrameworkPK_v4_1\Solutions\Netduino\DeviceCode\Blockstorage\Sam7X_blockstorage
- reflash my arduino
Well, just make sure you reflash your Netduino with the firmware as well. Just teasing.
The problem is that code generated by GCC does not fit into flash segments, hardcoded as a table in bootloader, which must be changed - I have already written about this in different thread.
The problem is that code generated by GCC does not fit into flash segments, hardcoded as a table in bootloader, which must be changed - I have already written about this in different thread.
Thanks Chris & CW2 for your help,
CW2, may you confirm that I don't need to change scatterfiles in any case (even if I add some new assembly in firmware, but that's not my case at this time) ? Because, when I don't change this file, I always receive an error at compile time (LR_FLASH bla bla bla) ... Even if I change the blockrange value.
Before starting any native code, I need to be able to rebuild successfuly a firmware with GCC. I don't have RVDS.
Is RVDS expensive ? Difficult to find any price !!!
CW2, may you confirm that I don't need to change scatterfiles in any case (even if I add some new assembly in firmware, but that's not my case at this time) ?
I had to change scatterfile to match the blockrange - for example, I changed Code_BaseAddress to 0x116000, where the first BLOCKTYPE_CODE started (adjusted to accomodate ~81KB bootloader).
Is RVDS expensive ? Difficult to find any price !!!
I use an evaluation of RVDS 4.1 Pro (registration required for download link). I don't know how much is it, but the fact you must ask for a quote indicates it is not cheap.
I had to change scatterfile to match the blockrange - for example, I changed Code_BaseAddress to 0x116000, where the first BLOCKTYPE_CODE started (adjusted to accomodate ~81KB bootloader).
I use an evaluation of RVDS 4.1 Pro (registration required for download link). I don't know how much is it, but the fact you must ask for a quote indicates it is not cheap.
Hi, maybe I'm little late but : is there any task to do with Solution Wizard provided by MF PK ? Maybe setting something related to the RAM of the device ?
Thanks