This could be because the two netduinos end up having the same MAC address, how is the MAC address set on a netduino, do they come with different MAC addresses from the factory, and if so, where is it stored?

I would like to know the above for the NP2 as well?

- Ulrik

I have a NP2 and cannot set the MAC address, so maybe the OP does indeed have two with same address on LAN. My unit does have an address printed on the back, and MFDeploy does in fact show that address (even without my having explicitly setting it), however my DHCP server clearly shows the request from 00:04:a3:00:00:00 which a Microchip address, presumably a factory default for the ENC28J60.

For now I'm motoring on with my project, but this will have to be fixed at some point...

...
This is a glitch in the ENC28J60 driver implementation....
...
In the meantime, have you tried setting your MAC address in code?
http://msdn.microsof...y/cc532879.aspx
...

Interesting. OK, I did try several things. Basically it's doesn't work in general, but it was still interesting. I'll show you my test code for what it's worth:

public static void Main()
        {
            NetworkInterface[] ani = NetworkInterface.GetAllNetworkInterfaces();
            foreach ( NetworkInterface ni in ani )
            {
                string strIPorig = ni.IPAddress;
                byte[] abyMACorig = ni.PhysicalAddress;
                ni.ReleaseDhcpLease();
                string strIPrel = ni.IPAddress;
                byte[] abyMACset = new byte[] { 0x5c, 0x86, 0x4a, 0x01, 0x23, 0x45 };    //<== I changed last three for this post
                ni.PhysicalAddress = abyMACset;
                ni.RenewDhcpLease();
                byte[] abyMACnew = ni.PhysicalAddress;
                string strIPnew = ni.IPAddress;
            }

        }

OK, some things:
* network intialization and dhcp has happened before Main, so it's mostly too late to change MAC via application code
* after PhysicalAddress setter, pinging fails to netduino as one might expect
* as you can see I attempted to work around by doing explicit DHCP release/renew around the change. These calls stimulate no actual DHCP activity, alas.
* the PhysicalAddress set action does persist across reboot, however. E.g., upon exist of this program, if I re-run it in the debugger, I have the new MAC address. and DHCP serves up the expected IP I reserved for this experiment.
* upon powercycling, though, this is lost, so it's not that interesting
* I guess if there was a was for the app to detect that it is a cold boot, set the address, do a warm boot, and then detect it is a warm boot and continue running, then that would be a possible work-around.

I would fix the firmware myself, but it is not clear to me how to build it, and I couldn't find anything interesting in the source I downloaded so I probably don't have the full package. I was somewhat expecting the Microchip code for the ENC28J60 somewhere, but couldn't find that either. Obviously I an assuming you are using that code at all, but I think the address is set in StackTsk.h in their code.

Anyway, I can carry on with other aspects of the project for now; I won't require two boards on the same network yet, but eventually I will.

-dave

Chris May not have taken in to account the Thanksgiving Holiday here in the USA. Most companies are closed on the 22nd and 23rd.

We do? I was wondering why traffic was so nice! I thought the apocalypse happened while I was sleeping...

But more on-topic: Is there any established practice whereby users can implement and submit the bugfixes to the firmware? I can't mess with this network one until this weekend, alas, so may be too late for this go-round, but I'm sure someone may have already fixed it or some of the others. Oh, btw, there's a network problem with DHCP configuration also, but you won't really notice it until you have more than one board. We all have the same MAC address right now!

-dave

for posterity of this thread, the 4.2.1.2 firmware does fix the 'mac address not setup from flash config' issue, so you should be good to use two NP2 on same LAN segment now. if you upgrade your flash, don't forget to re-set the MAC with mfdeploy.exe, since the flash upgrade will erase it. -dave

And when i do it works perfectly, i'm only setting the MAC, as i use DHCP.
That [[OTP setting of MAC]] will be welcomed, especially because the MAC address is printed on the board.
- Ulrik

In truth, personally, I'd prefer to not be constrained to OTP MAC address. Or more precisely, I'd prefer to have the ability to override the OTP setting, something logically like this pseudocode:

effectiveMAC = ( 0 == configMAC ) ? otpMAC : configMAC

-dave

Snazz-y! I like the 4-voice pwm synth, too! (haha).

MFDeploy is not a browser based tool; rather it is a destop native application accesses the CLRon our board via USB (typcially, but certainly with the NP2).


It is part of the .NetMF SDK installation, and you can reach it from the Start menu:
start -> all programs -> microsoft .net micro framework 4.2 -> tools
this is actually a folder link which will open up the folder containing various .netmf4.2 tools, amongst which is the MFDeploy.exe.

There is also a help file that details it's usage, but the short story for your purspose is to set 'device' to 'usb' (which should then show 'NetduinoPlus2_Netduino' if it successfully connects),
and then:
Target -> Configuration -> Network
will bring up a dialog box with the various networking options.

Once you set this to your choosing, you should be good.

Well, except for one caveat:
* a bug in pre 4.2.1.2 firmware ignores these settings
You can see your firmware version via
Target - > Device Capabilities
which will spew forth many interesting things, including a line starting with:
SolutionReleaseInfo.solutionVersion
which should show at least 4.2.1.2 to be free of the bug. This is a very recent firmware fix at the time of this writing, so you probably need it if you haven't explicitly updated your board. There's a separate (pinned) thread in this topic on how to perform that update. (I don't know how to link or else I would, but you can find it easily).

-rave

... People that are new into electronics often forget that contacts bounces, and the MCU they are using is fast enough to detect that, several times for every press/change. ...

That being said, I am curious: do you find that the glitch filter option of the input port to be ineffective? debounce is truly one of my very least favorite chores, so I was pleased to see this in .NETMF

-dave

The glitch filter does not help much to handle debouncing, because it samples the input during very short time period, usually only a few microseconds...

Oh, interesting, I thought keybounce was the whole raison detre for glitch filter. Actually googling "netmf glitch filter" yields some indications that this is the intended purpose (e.g. first hit http://wiki.microfra.../index.php/GPIO and also the Microsoft http://msdn.microsof...y/cc532245.aspx); not that I believe everything I read on the web! But yes microseconds is too short, I usually use 20-50ms in my c/asm code implementations...



-dave

I'm using the 4.7.2 yagarto toolchain, but I can't complete the build right now because of function signature mismatch in
CLR_RT_HeapCluster.cpp for HeapCluster_Initialize

It appears that TinyCLR_Runtime.h and also Execution.cpp in the source are oriented towards an older version of .netmf where HeapCluster_Initialize() took one parameter, instead of two as in the 4.2QFE2 version. It's not yet obvious to me how to correct it myself properly, but then I haven't spent any time on it yet. But otherwise there was about nine minutes of compiling happening, so thats a start.

-dave

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).

Yes, haha, at length I did figure out that. Now it seems I am down to 'scatterfile' problems, so I'll need to figure out how those work. They seem to be some sort of memory map definition for the resultant image.

I did find what seems to be a genuine bug;
* C:\Experiments\netduino\netduino_plus_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_PWM\STM32_pwm_functions.cpp:284
I'm pretty sure that should be a == (comparison) instead of an = (assignment). And also a lesser quasi-bug:
* C:\Experiments\netduino\netduino_plus_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_USB\STM32_usb_functions.cpp:417
for my setup, __packed is not defined, and I resolved this by adding

#if defined(__GNUC__)
#define __packed    __attribute__ 
((__packed__))
#endif

before that line. I say this is a quasi-bug because I somehow feel unclean about my 'fix', that there is a better place for that definition, and that maybe it should have been picked up.

Oh well, it's compiling now, which was a feat, so on to scatterflies for the moment.

-dave

Good eye, Dave. Good eye. That shouldn't have any adverse effect, but we'll be sure to check it into the next revision.
Thanks for helping us all get GCC up and running.

Yeah it looked minor.
Well, no need to break out any champange yet on the gcc build:

region `LR_FLASH' overflowed by 164760 bytes

and I guess I have to make a scatterfile for the tinybooter from scratch, since it wasn't in the source bundle. Do I really need to make a tinybooter? Can I not just keep the existing (production) one on the flash? I'm eager to smoketest a binary built from this toolchain.

-dave

No need to rebuild the TinyBooter. You can use the one that's already in flash (and much smaller, thanks to RVCT).
One of the nice things about having 384KB of codespace on Netduino Plus 2 is that you can shrink that sector to 128KB/256KB and have tons of room for GCC-built firmware. If you change the flash layout (and GCC scatter file for TinyCLR) you should have room to flash the larger firmware and still have quite a bit of codespace left over.

groovy; one less thing to do for starter. I did change the scatterfile to accomodate the larger image (it looks like the config area is immediately after it, so I just moved that up by the needed amount. And I may be moving again, since I have a couple unresolved symbols. Some D-to-A related stuff it looks like; I don't think we even have any on this board...

-dave

at length it did build... something! It's not a dfu file like what I'm used to for flashing the firmware updates,but I have a tinyclr.axf and some sundry bin and hex files. the hex files appear to be motorola s records. I don't know if I should be concerned that my ER_DAT (bin) files is 0 bytes. Maybe we'll see later when I have access to the board....

Thanks, I look forward to bricking my NP2 this eve! JTAG - don't have any of that on-hand, alas. wiki -- oh! I'll definitely have to check that out; maybe I wasted a lot of time figuring some things out the hard way! My last concern of the moment is that my gcc tinyclr scatterfile did not have a Deploy_BaseAddress listed, and I did increase the flash area for tinyclr. I wonder if I should be concerned, or if TinyBooter now has the ability to figure that out without being rebuilt in sync with the tiny clr... -dave

I did make a brick. well, a light brick; it was easy enough to flash back. What an odd little tool, the dfu_file_manager. I was wondering why I needed to put in an address, since all that info is in the s-files, until I realized that you must use bin files if you are going to have more than one file make up your image. sheesh. Anyway, the first burn was of the literal s-file data haha I could see all the ascii in the flash image, so /that/ didn't work! but the second, proper, one didn't either, so more work to do, alas. It's not clear why I need to shrink any (deployment) code sectors; this is an RG device, so it has 1MB flash, so it seems there's a few hundred k headroom for the tiny clr. But not a total loss; one thing I wanted was to get the map file to analyze. If someone has a map file generated from RVDS for the NP2 firmware, I would love to have it so I can study/compare in-depth. And really, if the rvds outputs a dump file like gcc does, I'd very much like that, too... In the meantime, now that I have failed, and as I slink away defeated, I at least have gained opportunity to start over with QFE1... -rave

...also the bootloader must be rebuilt and reflashed, when those change (assuming the bootloader is used at all)....

One thing to keep in mind is that STM32F4 flash memory is organized into several sectors of different size, so you'd need to layout the .NET MF flash memory appropriately....

I have managed to get GCC-built firmware working on NetduinoGo...

Thanks so much for the advice CW2; I think what I meant by being surprised about needing to shrink deployment is that, in the NP2, it appears that the deployment area is already set to be the top 384k of flash, leaving the bottom 640k for tinclr/config, etc. The rvds-built firmware is much smaller than the gcc. leaving a huge gap before risking colliding with deployment at 080a0000, so it /seemed/ I can get away without rebuilding/reflashing tinybooter.

Speaking of flash surprises, I did notice the variable sector sizes in the datashet and was surprised config was not placed in a lower, 16k sector. Moreover in the original firmware source bundle, it has config at

"Config_BaseAddress"  Value="0x08046800"

which is not aligned to any sector at all. This surprised me, because I would imagine that whenever you use mfdeploy to tweak values, you would be erasing a bunch of nearby stuff also in the same sector? Maybe my understanding of the use of the config sector is way off?

I definitely will take a peek at your Go project's config. Googling obviously turned up your posts many times while I was tryign to get this far, and it was most helpful.

Ultimately, I am trying to build the firmware successfully without (too many) mods, and then to add various crypto and ssl support, and also to analyze the build size issue and see if I can maybe mod the libs to reduce it. (But it is nice to see that I have a lot of headroom before I have to optimze that way). I am too poor for rvds, and I have a hard time believing gcc is that bad -- I've used it for years, but I need to prove it first, rather than speculate (hence my plea for someone's rvds linker map file).

-dave

[edit] I feel a bit naive, I think I was assuming the gcc scatterfile out of the source bundle was sane to begin with, but looking at the rvds file, /that/ one looks sane and jibes with my thinking outlaid above. Also, on a wild hare, I dumped the official firmware with dfu and Lo! and Behold! it also jibes. (I suppose I could even use its tinybooter image, maybe). So probably some more board bricking is in my future!

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!

Just FYI, both Netduino Go and Netduino Plus 2 expose SWD via the Cortex Debug Port (MiniJTAG header).

speaking of which, does someone know where I can get the tiny pin header for this port? for a couple bucks? I have a jtag interface and cable for that header coming, but I will still need to solder on the pin header to the board.
-dave

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.

all of it (the original 384k).

 

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.

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 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:

http://wiki.netduino...hx?NoRedirect=1

 

-dave