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

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

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

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

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

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

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

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

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

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

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

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

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

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

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