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.
In my experience, anything related to configuration, especially things like memory layout is better to be considered completely wrong, until proven...
...
I am not sure if it is still available, but there was trial version of ARM RVDS available for download, limited to 30 days or so. The main problem with GCC is the size of printf-family functions in C/C++ runtime, but the default newlib implementation can be tweaked a little bit to produce smaller code, if ...
teehee, yes as per my edit, I should have known better. Oh, well, it provided a learning opportunty.
yes, rvds 30day trial. I was hoping to save myself for that special build However, I am a little surprised that the size diff is not that great in the NP2 firmware -- well not relative to the total size, that is. Its some 40 k heavier, which in my book is perfectly fine for a 400k image, with some 200k headroom. I'd still like to analyze the mapfile to prove once and for all that the code generation is on par, and that the crt is the (fixed) difference.
OK, time to edit scatterfiles again, and make some new bricks. I do wish I could step through the CRT code to get at least some feel that things are kind of working correctly, maybe I need to look into the JTAG stuff for that. I'm showing my age, but in my day JTAG was used for testing boards rather than firmware, and it was quite expensive. Hopefully things have changed. I have used ICSD on PIC for instance; thats cheap.
-dave
[edit] I made a new kind of brick; I fixed up my scatterfiles and used the tiny booter image I extracted from the official firmware to my make firmware. So now it does get into tiny booter (and stay there; I can connect with mfdeploy), but it doesn't hand off to tinyclr. So I guess I need to look at what tiny booter does to make it not like my binary. I wish there was a log or something like uboot that I could work with interactively!
Hey endo;
Well no, not as such just yet. Right now, I can build the firmware but it doesn't run. I have inspected the hex files, inspected the generated assembly code (a little bit, obviously not comprehensively), and even disassembled the official firmware for cross-reference of the startup routines as a sanity check.
I'm sure it's something silly, but without some debug output support I'm groping in the dark with compiler flags etc. Its a pity tiny booter isn't just a little bit better (like having some special mode to spew debug output over a serial port really shouldn't be much code increase).
But I am undaunted. At present I have on order a JTAG pod and also some pin headers to solder onto the board so I get get down and dirty and step the code. It'll probably be something stupid, like a stray ARM instruction somewhere that is throwing a fault, or something even more mundane. I won't be able to get back to it meaningfully for a couple weeks while waiting for the test equipment to ber delivered, and also because I'll be out-of-town. When I get it working I'll be sure to post, with patchfiles to the source tree, and detailed step-by-step instructions from setting up the tool chain to flashing the built image.
-dave
yay, jtag pods and micro 10pin adapters and pin headers and soldering has happened. and I downloaded, installed, configured, and ran OpenOCD and can connect to it. Because I don't know gdb natively, I also installed Eclipse, the CDT, and am configuring that. There is no 'elf' output file from the build (that I can see), so I have to think about that some more....
Edit: looks like the AXF file is in fact, an elf file. cuz we need more filename extensions, I suppose. Anyway, at length I have debugged past the boot loader, into the tinyclr, and fairly early in the process it goes off the rails with an illegal instruction. At present it looks like the PrepareImageRegions is where the fault is stimulated, so I need to look at that some more...
Edit2: I discovered that the stack was smashed during Prepare_Zero; I disassembled the stock firmware for comparison and discovered some erroneous constants stemming from scatterfile errors. I corrected those and got past that crash, but have happened upon another one in HAL_Initialize(), so the process continues. This time it seems to happen at ENABLE_INTERRUPTS(), and interestingly doesn't happen when I single-step, only when I 'continue' through it, so maybe some interrupt aspect is wrong...
Edit3: I discovered a couple more scatterfile problems involving placement of the interrupt vectors and the 'custom heap', I am still trapping, however I notice a curiosity: In the disassembled firmware, the vector addresses are odd, and in the built firmware, they are even. Looking in the armarm (for v7m) I see that the low bit MUST be set, so I am really curious as to why this is not being done for the gcc build; almost like an arm/thumb problem.
Edit4: Well, I got it to the point that I can connect with the MF Deployment tool, and ping, and get Device Capabilities, so it's getting there. However PlugIn Debug Show Device Info faults, so still more work to do. I also wish there was a comprehensive test app so that I can get some code coverage, to weed out any other faults. I'm still distressed about the item described in Edit3, which I worked-around in the interim by explicitly setting the low bit, but I'm sure that's not the 'correct' fix.
Success! I have built the 4.2.1.2 firmware with the yagarto gcc 4.6, did things with the MFDeploy, and have made a blinky and deployed and stepped through the app with the debugger in VS2010. I do wish there was a comprehensive (even if only slightly so) 'unit test' app to validate the build, but I'm going to call it macaroni for now.
Shoutout to Valkyrie-MT for advice and also reference to another gcc-derived tool chain that may be more well-behaved than the yag, and especially to CW2 for giving me the final incantation needed to make the linker not do army things for thumbs when linking assembler objects.
Its odd. I have never been so pleased to labor so hard to acquire what I already had to start with.
Hi ziggurat29,
That's awesome! How much free flash do you have for your application afterwards?
Having enough flash to build your own firmware--without losing any board features--was a major goal with Netduino gen2.
Chris
There was enough (plenty enough) space in the original partitioning to accomodate the tinyCLR as-is. This was a good thing, too, because I can't say the same for the TinyBooter, however because the partitioning did not change, I could use the 'official' firmware tiny booter with the gcc-built tiny clr. For reference, the image is about 10% bigger than the official build (446k vs 404k).
I do intend to work on the (not quite so) tiny booter next, when I get back. It doesn't quite fit into the 48k as currently partitioned, alas, but there is an unused 64k to which I could avail myself for some of the code if I get busy with the scatterfile.
I do intend to work on the (not quite so) tiny booter next, when I get back. It doesn't quite fit into the 48k as currently partitioned, alas, but there is an unused 64k to which I could avail myself for some of the code if I get busy with the scatterfile.
Just FYI, TinyBooter is mostly just a convenience. The only reason we have it there is so that you can change the network settings from MFDeploy. You can just remove it and regain that 48KB as well if you'd like
The block partitioning might be a bit odd, using the first 64KB for TinyCLR...but you can create an ER_BOOT block there (like we do on the Shield Base) if you want the first 16KB to just include jump instructions so you can move TinyCLR to other sectors.
Chris
OK, and finally I got the TinyBooter to work. I 'cheated' a little in that I tried out the 'GCC Tools for ARM Embedded' toolchain, instead of the Yagarto as I had been using. It has a modded newlib (newlib.nano) that is smaller than yagarto's newlib, and that got the code side down to where tiny booter would fit as originally planned. Now I'm going to clean it up and write up the whole process.
I notice that in the meanwhile, an new versionof the firmware has been released 4.2.2.0? If you would please post that source so I can move the mods to it. On the plus side I accidentally started this with QFE2, so I am familiar with the changes in the PK (gcc support is a little less goofy).
I am not sure if it is still available, but there was trial version of ARM RVDS available for download, limited to 30 days or so.
I recently downloaded RVDS so the trial was still available. Took a while to install but worked fine. I haven't tried to compile the firmware yet but that's on my next weeks schedule.
I recently downloaded RVDS so the trial was still available. Took a while to install but worked fine. I haven't tried to compule the firmware yet but that's on my next weeks schedule.
Then you should have far (far) less trouble building. As for me, I expect I'll be needing more than the 30 days to do ongoing work (and I have to admit I find usd$5000 for a compiler to be vexing), hence this past month's effort to get a serviceable gcc build working. But now I can get back to the original task of putting in some crypto....
I did write up the process, and also produced a kind of kit of sorts, and put it on the wiki (which seemed the appropriate place) here:
<blockquote class="ipsBlockquote" data-author="Chris Walker" data-cid="41271" data-time="1355067270">Hi Dave,<br />
<br />
<br />
The Netduino Plus 2 firmware is based off of .NET MF 4.2 QFE1 so be sure to copy it over the 4.2 QFE1 PK (instead of 4.2 QFE2).<br />
<br />
Chris</blockquote>
<p>Hi guys,</p>
<p> </p>
<p>Kind of sad, because one of the additions in QFE2 was GCC support :-( </p>
<p>I am trying to build some small interop additions with GCC on N+2 (I used a 30-day RVDS trial to build the previous version on Netduino Plus, but that's expired). I will follow through ziggurat29's procedures (I see they were just updated yesterday); just wanted to know if there's a change to that one.</p>
<p> </p>
<p>Happy Monday!</p>
<p>Howie</p>
Edited by Howie Goodell, 14 January 2013 - 07:43 PM.
I had finally gotten it to work (CLR run without crashing or other odd behaviour) last week, and I finally wrote up and posted yesterday.
Yes QFE2 has better gcc support. Better in the sense of supporting a toolchain, but the various code edits and scatterfile and tool options changes are still needed.
Coincidentally, I accidentally started out with QFE2, so I'm pretty familiar with it. When the 4.2.2.0 source is posted (allegedly in the next week or so), I'll mod it, too, to be up-to-date. That latest release is based on the QFE2. Should be a quicky.
One little nit is that saying GCC4.6 or 4.7 returns a stupid error -- the script setenv_base.cmd has all the sophistication of a 1985 DOS script and throws me out if I say anything other than GCC 4.2:
C:MicroFrameworkPK_v4_2>setenv_base.cmd GCC4.6 PORT C:yagarto
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
Error: Invalid Arguments!
Usage: setenv_base COMPILER_TOOL_VERSION
where COMPILER_TOOL_VERSION is ADI5.0, GCC4.2, ADS1.2, RVDS3.0, RVDS3.1,
Idiots! However, just tell it you want 4.2 and it's happy:
C:MicroFrameworkPK_v4_2>setenv_base.cmd GCC4.2 PORT C:yagarto
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
setting vars for GCC compiler
Is this legitimate? Also wondering why you don't have the error. Is it possible you still have the QE2 script executing? I think the nonsense about versions was fixed there.
I also still have 2 compile errors, but I just realized I had installed the latest GCC (4.7) instead of 4.6.0 (2l0111124) as you instructed. I'll correct that before whining further ;-)
Idiots! However, just tell it you want 4.2 and it's happy:
C:MicroFrameworkPK_v4_2>setenv_base.cmd GCC4.2 PORT C:yagarto
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
setting vars for GCC compiler
Is this legitimate? Also wondering why you don't have the error. Is it possible you still have the QE2 script executing? I think the nonsense about versions was fixed there.
I also still have 2 compile errors, but I just realized I had installed the latest GCC (4.7) instead of 4.6.0 (2l0111124) as you instructed. I'll correct that before whining further ;-)
...
I did have to mod setenv_base.cmd for the other version number (only 4.2 came out-of-box). I also failed to include that modded file in the archive (though the changes should be in the patchfile). The version gets used to build some path name, so I imagine it is important. I updated the bundle I attached to the wiki (apparently I cannot delete the old one, but the date code will disambiguate).
I'm concerned about the two compile errors, should should be none (unless they are 'can't include file xxx' because of the version number issue).
I usually use setenv_gcc, for example
setenv_gcc 4.7.3 C:GCCGNUToolsForArm
I think that works for QFE2, but QFE1 has the hard-coded version numbers, so only one parameter is accepted in that script. BTW I had to back off of GNU Tools for ARM for the moment. It seemed to work OK with regular newlib, but was not reliable (in my case) with newlib.nano, alas. Interestingly it had a code generation issue in FirstEntry.s, where it would emit a 32bit instruction for the first jump, instead of 16bit. I had to make it explicitly b.n. But I do intend to go back to it at some point if I can make the newlib.nano work; the size is good.
I'm concerned about the two compile errors, should should be none (unless they are 'can't include file xxx' because of the version number issue)
FYI Dave, changing the YAGARTO version didn't fix it, but the change to set_base_env.cmd did. I now get 20 warnings and no errors, same as you. Yippee! And thanks a bunch for your hard work!
Now to see if it boots....
Howie
Hmmn -- I made a DFU image following the wiki instructions, but it doesn't ping in MFDeploy. Reflashing the release one (from wlhich I extracted TinyBooter) does. What to do?
I have the ST-LINK/V2 dongle and adapter Chris recommended; verified I can see program memory and registers with JTAG ifc using STM's utility. I also set up Eclipse and verified I could build a test ARM program; just have to get those together; good idea anyway. Dave, I'll go look at your posts from earlier and start debugging this in hardware, unless you can suggest something obvious I might have missed here. Anybody have ideas?
Thanks!
Howie
Edited by Howie Goodell, 15 January 2013 - 09:09 PM.
Hmm, doesn't ping, probably means firmware hosed somehow! If the tinybooter dislikes the clr, it will stay in the tinybooter, and ping will return 'TinyBooter' instead of 'TinyClr'. But that check is very rudimentary -- just the 'signature' word, so things can easily go wrong after that.
Broadly the things I had to fix were:
* lots of scatterfile problems; memory not laid out correctly
* some address fixup issues -- linker was using even addresses instead of odd when linking various assembly modules.
both of those would cause non-booting. Beyond that were tool configuration things, but those failures usually prevented the build from completing.
Yes the STMLink; we're buddies now. (except when USB enumerates, it tends to drop on me, invalidating my test). I used the OpenOCD and gdb.
I'll be happy to look at your tinyclr.afxdump while the problem areas are still fresh in my head. Actually, if you want, send me the tinyclr.axf, tinyclr.axfdump, tinyclr.map, and ER_FLASH, then I can debug also.
Fortunately I'm a harmless idiot. I rechecked everything and found that I had copied the wrong block of the release version into the TinyBooter slot. As you diagnose, failure to return anything to the ping points straight at the boot code. With the correct version, it pings TinyCLR. Excellent!
I am trying to get MSVS 10 to deploy now; may be back with a question or two about configuration or setting up hardware debug shortly. However, I am seeing how much work you did to get this toolchain running, and I really appreciate it. I think the price point and free-as-in-speech nature of GCC will open up interop on this board to a lot more people.
Ah, thank goodness. It's a lot of moving pieces -- I've certainly mis-built firmware myself plenty of times. I wish the dfu building was a little more automatable... Thanks so much for sticking with it and sanity checking the procedure (and finding my bug in missing the setenv_base.cmd file).
Totally agree; having a free toolchain should only make it more likely folks will extend the platform in interesting ways. Plus, enable folks to help fix bugs, too!
The block partitioning might be a bit odd, using the first 64KB for TinyCLR...but you can create an ER_BOOT block there (like we do on the Shield Base) if you want the first 16KB to just include jump instructions so you can move TinyCLR to other sectors.
Chris
