Hi Support,
What version GCC can be used for compiling this firmware on the Netduino plus 2 source?
Is there any recomendation excluding RVDS?
I tried to compile the default source with "arm-2007q3-53-arm-none-eabi.exe"
It is giving several errors the target CPU does not support ARM mode.
Thanks!
GCC Compiler for Netduino 2 plus source
Started by endo, Dec 07 2012 04:13 PM
19 replies to this topic
#2
Chris Walker
-
- Moderators
-
- 7767 posts
Secret Labs Staff
- LocationNew York, NY
Posted 07 December 2012 - 04:24 PM
Hi endo,
That's probably a question best answered by CW2 or KodeDaemon. They did a lot of work around adding GCC support for THUMB2 micros to NETMF. I believe that you need the newer version of GCC for THUMB2 (Cortex-M3/M4) support.
The official firmware is compiled with RVCT 4.1 (RVDS/MDK).
Chris
#3
neslekkim
-
- Members
-
- 350 posts
Advanced Member
- LocationOslo, Norway
Posted 24 January 2013 - 01:41 AM
--
Asbjørn
#4
ziggurat29
-
- Members
-
- 244 posts
Advanced Member
Posted 24 January 2013 - 02:21 AM
I wonder if this release of GCC will help us a bit?
I tried and failed. But I have hope. There seems to be something with gcc 4.7 that I haven't figured out yet. I can make a stable firmware image with gcc 4.6, but with gcc 4.7 I get an unstable image (by unstable I mean that some things work, like MFDeploy functions, but the board malfunctions when I try to use Visual Studio to deploy and debug).
I haven't had time to dig into the 4.7 issue yet, so personally I'm carrying on with 4.6 for now, which has been quite stable.
I described it in a separate thread, and summarized the process, and the needed changes, in a wiki article:
http://wiki.netduino...to-GCC-4-6.ashx
a few people have pm'ed me indicating success with the procedure.
But I am motivated to make 4.7 work as soon as practically possible; the 'newlib.nano' packaged with the ARM tools you mentioned actually results in smaller binaries than the RVDS toolchain produces. Of course, it has to run, though. At first I thought the newlib.nano was the problem, but I compiled with yagarto 4.7 (which has larger, plain ol' 'newlib') and it exhibited the same problems, so I feel it something with code generation in gcc 4.7 (or maybe the bundled assembler). I know that some defaults changed, and I adjusted for the ones I knew about but it didn't do the trick. So more work!
I'm also motivated to make an update for the 4.2.2.0 firmware, as soon at that source gets posted for download.
-dave
#5
Chris Walker
-
- Moderators
-
- 7767 posts
Secret Labs Staff
- LocationNew York, NY
Posted 24 January 2013 - 03:17 AM
Hi Dave,
Chris
Good news: we posted it a bit earlier today, over on the Downloads page...I'm also motivated to make an update for the 4.2.2.0 firmware, as soon at that source gets posted for download.
Chris
#6
ziggurat29
-
- Members
-
- 244 posts
Advanced Member
Posted 24 January 2013 - 03:42 AM
Hi Dave,Good news: we posted it a bit earlier today, over on the Downloads page...
Holy cow! Happy news indeed. Two questions:
1) this new version, 4.2.2.0, is based upon QFE2, right? Or still qfe1?
2) since the new source bundle invalidates the information in wiki article stating 'get the source bundle... (link)... apply my changes...' (since my changes are to the 4.2.1.2 code), would you mind my attaching the older 4.2.1.2 source bundle to that article? so that the information therein is forever consistent?
-dave
#7
Chris Walker
-
- Moderators
-
- 7767 posts
Secret Labs Staff
- LocationNew York, NY
Posted 24 January 2013 - 03:56 AM
Hi Dave,
The new version is based on QFE1. QFE2 was required for Netduino gen1 to be stable with the new NETMF 4.2 firmware. But Netduino gen2 was designed to work great with QFE1.
That said, we'll be upgrading the firmware to NETMF 4.3, which includes all the QFE2 updates as well. Instead of doing an interim QFE2 update for the gen2 boards, we're moving straight to 4.3.
Chris
P.S. The best thing for that Wiki article may be to link to the downloads page (or to the actual download). We try to keep the target file name consistent across updates.
#8
ziggurat29
-
- Members
-
- 244 posts
Advanced Member
Posted 24 January 2013 - 05:17 AM
Ah, OK on the QFE1
...
P.S. The best thing for that Wiki article may be to link to the downloads page (or to the actual download). We try to keep the target file name consistent across updates.
well, that actually is my concern. As written, it does link to the download object, named 'netduinoplus2firmware.zip'; however, at the time of writing, the link that was for the 4.2.1.2 source, and now it links to 4.2.2.0.
Since the code/config changes described in the article are specific to the version 4.2.1.2, that information is now effectively invalid since it won't work without further effort on the reader's part to figure out how to further port it up to the actual version for which 'netduinoplus2firmware.zip' is at the time of download.
My thinking is that, as a quicky, I can merely attach the relevant bundle to the article, and edit the text to say 'get it from the attachements'. As a longy, you could change your publication practice to have version info in the filenames, and/or provide links to previous versions, e.g. sourceforge. But I don't expect the latter to happen without forethought and effort, so the former seemed cheap and effective.
-dave
p.s. -- You know how it is, folks aren't building the firmware for the niftiness of having built it, they are building it to get some weird hardware (or software) integrated. They don't want to know how or why the build system has to be twisted, they just want some reliable steps to get it all set up so they can begin to tend to the original work at hand.
#9
CW2
-
- Members
-
- 1592 posts
Advanced Member
- LocationCzech Republic
Posted 24 January 2013 - 07:42 AM
There seems to be something with gcc 4.7 that I haven't figured out yet. I can make a stable firmware image with gcc 4.6, but with gcc 4.7 I get an unstable image (by unstable I mean that some things work, like MFDeploy functions, but the board malfunctions when I try to use Visual Studio to deploy and debug).
I have experienced probably the same issue with Netduino (gen. 1) firmware compiled with GCC 4.7 - it seems everything works fine, except the Visual Studio deployment. I was able to identify the cause of failed deployment: it is because the board does not acknowledge message that requests write of the deployed assembly to flash memory and the acknowledge is not sent (resp. NACK is sent) due to invalid CRC. I suspect there is either problem in some time-critical code, or for example memory access bug (buffer overrun?), because the ACK response started to being sent correctly after I added some diagnostic output to message processing routines. Nonetheless, it is not easy to troubleshoot this, so I am looking forward to your findings...
#10
ziggurat29
-
- Members
-
- 244 posts
Advanced Member
Posted 24 January 2013 - 01:22 PM
... I suspect there is either problem in some time-critical code, or for example memory access bug (buffer overrun?), because the ACK response started to being sent correctly after I added some diagnostic output to message processing routines. Nonetheless, it is not easy to troubleshoot this, so I am looking forward to your findings...
Wow, now thats news I can use; thanks so much for digging into it and relating your findings, it will definitely help me focus my efforts.
In a way, I was hoping it was a garden-variety code generation error which I could fix with, say, compiler flags, but maybe it is actually a fundamental bug (e.g. race condition that got unmasked) and that's is a better problem to have? No? Well, I am going to spend some QT with the ND this weekend. I need to work on my 'real' project since that deadline's looming, but I have become a bit obsessed with this firmware building problem for some reason.
#11
neslekkim
-
- Members
-
- 350 posts
Advanced Member
- LocationOslo, Norway
Posted 24 January 2013 - 01:24 PM
It's way better to have an race condition due to an code bug, than an bug due to an compiler that generates code wrong
--
Asbjørn
#12
ziggurat29
-
- Members
-
- 244 posts
Advanced Member
Posted 24 January 2013 - 01:37 PM
It's way better to have an race condition due to an code bug, than an bug due to an compiler that generates code wrong
Haha, yeah. Well, I was meaning less wrong in a 'fundamentally wrong' sense, but more 'the compiler made a choice which is technically valid, but the code wasn't explicit that the particular choice wasn't appropriate given the context'. Case in point: the first instruction of the TinyCLR is a jump. It was coded as 'B Start'. This can compile to 0xE00C, but it can also legally compile to a 32-bit version (can't recall the opcode). This actually happened between 4.6 and 4.7. I 'fixed' it by changing it to 'B.n Start' which is unambiguous and means 'you must use the 16 bit encoding'. If you use the 32 bit version, the jump works fine, but the interrupt vector table that is placed after it in memory is skewed by half a word, and then Hell does quickly break loose!
#13
CW2
-
- Members
-
- 1592 posts
Advanced Member
- LocationCzech Republic
Posted 24 January 2013 - 01:40 PM
In a way, I was hoping it was a garden-variety code generation error which I could fix with, say, compiler flags, but maybe it is actually a fundamental bug (e.g. race condition that got unmasked) and that's is a better problem to have? No?
It's way better to have an race condition due to an code bug, than an bug due to an compiler that generates code wrong
Originally, I also kind of hoped it was some fundamental code generation-related bug, which would be easy to identify (e.g. fault/exception, wrong instruction emitted etc.). I am not sure a race condition is better, because in this particular case it would happen in code that handles USB communication, which means basically no way to debug it and very limited ways for diagnostics (debugging output significantly affects the timing of execution).
I can make a stable firmware image with gcc 4.6, but with gcc 4.7 I get an unstable image
This is something I have to try - compare the output of GCC 4.6 and 4.7...
#14
neslekkim
-
- Members
-
- 350 posts
Advanced Member
- LocationOslo, Norway
Posted 24 January 2013 - 01:51 PM
Originally, I also kind of hoped it was some fundamental code generation-related bug, which would be easy to identify (e.g. fault/exception, wrong instruction emitted etc.). I am not sure a race condition is better, because in this particular case it would happen in code that handles USB communication, which means basically no way to debug it and very limited ways for diagnostics (debugging output significantly affects the timing of execution).
Yes, raceconditions are very difficult to find and fix, but they can be fixed, code generation on the other hand is more difficult to find, and you could potentially have bugs all over your compiled code, and more difficult to get it fixed since everyone patches around it, and it will again break if someone fixes the compiler
I guess things like that doesn't happen so often anymore.. had my share of those bugs with some compileres in the beginning of 90's..
--
Asbjørn
#15
ziggurat29
-
- Members
-
- 244 posts
Advanced Member
Posted 24 January 2013 - 02:08 PM
.. basically no way to debug it and very limited ways for diagnostics (debugging output significantly affects the timing of execution).
This is something I have to try - compare the output of GCC 4.6 and 4.7...
yeah the bug that moves/hides when you look at it to debug. Isn't that a 'Heisenbug'? Hate it!
But I had a stray thought: you are using a board with the Atmel chip, and I'm using one with the ST Micro chip. Our clock speeds are wildly different, yet we're experiencing similar behaviour, so maybe there is a fait glimmer of hope that it isn't a race condition after all.
I started to compare the output but my first attempt was hopeless. I was diff'ing the axfdump and it is just not amenable as-is. Plus the various routines get put in different places which hoses my simple diffing. For my next attempt I was going to use the two compilers with the same prebuilt libs (which may croak for other reasons), and process the axfdumps to strip out the boring bits, like physical addresses.
...
I guess things like that doesn't happen so often anymore.. had my share of those bugs with some compileres in the beginning of 90's..
Yeah, reminds me of a COBOL project from way back, haha -- the compiler was so buggy that we wrote all these 'overlays' in assembly. The company was fearful if they upgraded from the circa 1986 MicroFocus compiler they were using, that they would introduce bugs, so this 'overlay' approach was their solution, haha. So I wrote a mini CXRT that conformed to the overlay spec so at least I could write my overlays in C++ instead of assembly. But it had become preposterous, since the cobol part incrementally did less and less of the products functionality -- it wound up being just a perverted hosting container.
#16
CW2
-
- Members
-
- 1592 posts
Advanced Member
- LocationCzech Republic
Posted 25 January 2013 - 07:58 AM
For my next attempt I was going to use the two compilers with the same prebuilt libs (which may croak for other reasons), and process the axfdumps to strip out the boring bits, like physical addresses.
Just a quick follow-up: I've built Netduino firmware with GCC 4.6.2 (4.6-2012-q4-update) and newlib-nano libraries from 4.7 (4.7-2012-q4-major) and it seems to be working rather fine, definitely more 'stable' than the one built with 4.7. I've compared the dumps and there is a lot of differences in the generated code, I'd need to dig a little bit deeper into that.
However, I've also found a serious problem: newlib-nano does not come with long-long support, so string formatting of 64-bit integers (C# long type) does not work correctly, "%lld" printf format is not recognized, it just outputs "ld". This also affects formatting of floating point numbers, because .NET MF uses its own implementation to workaround a bug in GCC and formats floating point numbers through use of integers and intermediate strings and long-long printf formats (see hal_snprintf_float() in tinycrt.cpp). I've hit this before in Yagarto and I was able to solve it by recompiling a custom version of newlib, but I am not sure the same can be done for newlib-nano - I recall reading something about long-long support being removed from newlib-nano, so I'll have to check that...
#17
ziggurat29
-
- Members
-
- 244 posts
Advanced Member
Posted 25 January 2013 - 01:37 PM
Just a quick follow-up: I've built Netduino firmware with GCC 4.6.2 (4.6-2012-q4-update) and newlib-nano libraries from 4.7 (4.7-2012-q4-major) and it seems to be working rather fine, definitely more 'stable' than the one built with 4.7. I've compared the dumps and there is a lot of differences in the generated code, I'd need to dig a little bit deeper into that.
However, I've also found a serious problem: newlib-nano does not come with long-long support, so string formatting of 64-bit integers (C# long type) does not work correctly, "%lld" printf format is not recognized, it just outputs "ld". This also affects formatting of floating point numbers, because .NET MF uses its own implementation to workaround a bug in GCC and formats floating point numbers through use of integers and intermediate strings and long-long printf formats (see hal_snprintf_float() in tinycrt.cpp). I've hit this before in Yagarto and I was able to solve it by recompiling a custom version of newlib, but I am not sure the same can be done for newlib-nano - I recall reading something about long-long support being removed from newlib-nano, so I'll have to check that...
That too is awesome news; I was going to try the same at some point to rule out the nanao vs compiler. Was building nano straightforward? I can probably mod the printf for longlong myself... I wonder if that is the only problem, or if more are in hiding...
#18
CW2
-
- Members
-
- 1592 posts
Advanced Member
- LocationCzech Republic
Posted 27 January 2013 - 11:49 AM
Yes, the building is straightforward, the source code includes very convenient build scripts.
One small tip: The command line statements in How-to-build-toolchain.pdf manual contains non-standard dash characters (probably em-dash) at a few places where it should be 'normal' minus sign. So when copy'n'pasted command does not work, it is most likely the case...
#19
ziggurat29
-
- Members
-
- 244 posts
Advanced Member
Posted 27 January 2013 - 05:00 PM
Groovy, I'll give it a go when I can get back to it. I have procrastinated my 'real' work for too long!. And thanks for the heads up on the cut-and-paste prob -- I can see that having taken me hours to find....
I did update the changeset/etc for the current 4.2.2.0 firmware, and posted an updated article for that:
http://wiki.netduino...to-GCC-4-6.ashx
I'm going to continue my work there, and retire from 4.2.1.2.
In that update, I also ported forward the Netduino2, and NetduinoShieldBase solutions. I don't have that hardware, so I can't test it, but I did at least scrutinize the build output carefully and it looks sane.
#20
wrljet
-
- Members
-
- 1 posts
New Member
Posted 15 July 2013 - 07:54 PM
I tried to follow the instructions in your blog post. I quite quite a few compiler warnings.
More than the 20 you mentioned. 0 errors.
But I am stuck at this point:
<<<
Use the 'DFU File Manager' from the 'DfuSe Demo' apps, to extract a binary from a dfu, to extract the pieces of the official firmware (we only need the Tinybooter). I.e. NetduinoPlus2_Firmware_4.2.1.2_00_08000000.bin
>>>
I don't know where to find the dfu needed for this extract.
And since we just built Tinybooter.bin why do we need to extracted it from an older dfu?
Hope I'm making sense.
Thanks,
Bill
I tried and failed. But I have hope. There seems to be something with gcc 4.7 that I haven't figured out yet. I can make a stable firmware image with gcc 4.6, but with gcc 4.7 I get an unstable image (by unstable I mean that some things work, like MFDeploy functions, but the board malfunctions when I try to use Visual Studio to deploy and debug).
I haven't had time to dig into the 4.7 issue yet, so personally I'm carrying on with 4.6 for now, which has been quite stable.
I described it in a separate thread, and summarized the process, and the needed changes, in a wiki article:
http://wiki.netduino...to-GCC-4-6.ashx
a few people have pm'ed me indicating success with the procedure.
But I am motivated to make 4.7 work as soon as practically possible; the 'newlib.nano' packaged with the ARM tools you mentioned actually results in smaller binaries than the RVDS toolchain produces. Of course, it has to run, though. At first I thought the newlib.nano was the problem, but I compiled with yagarto 4.7 (which has larger, plain ol' 'newlib') and it exhibited the same problems, so I feel it something with code generation in gcc 4.7 (or maybe the bundled assembler). I know that some defaults changed, and I adjusted for the ones I knew about but it didn't do the trick. So more work!
I'm also motivated to make an update for the 4.2.2.0 firmware, as soon at that source gets posted for download.
-dave
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
