Hi tridy.net,

Thank you very much for the feedback!

The Netduino SDK installer activates VS2012, VS2013 and VS2015 (including Express editions) in the background. It does this to install the universal Netduino Application template in the "New Projects" dialog. If one of those three Visual Studio versions has a partially-removed or needs-to-be-repaired installation, you could get an error like that.

Regardless: as long as you can create, deploy and debug apps...no worries If you run into troubles just let us know!

Chris

P.S. For reference, here is what the "New Project" dialog looked like with earlier SDKs.



Ugh. Just think of what this would have looked like in a few more years, with more than a dozen options.

So much cleaner now, with one universal template.

Hi kimrody,

With this current version (v1.0.0) the upgrade process is somewhat anticlimactic.

Should I assume that "anticlimactic" is a good thing? The goal is "simple"...hopefully we struck a good balance.

Chris

Hi Jens,

Here you go:
http://forums.netdui...o-2013-support/

Chris

Hi rolandwolters,

 

Yes, when you deploy your app it's stored in the flash of the device.  When you power up the device, the app will run automatically.

 

If the app doesn't start up, it likely wasn't actually deployed.  If you open up MFDeploy, press F5 to connect, reboot your board and press Ping...you should get a data dump of the board's boot process--including what app it loaded.

 

If you run 4.2 firmware on your board, does that deploy/debug alright?  This may be a WinUSB-in-4.3 issue...

 

Chris

Hi rolandwolters,

What happens if you reboot the device (by pressing the pushbutton) while the debugger is having trouble attaching?

This sounds like it may be an MFUSB glitch in the 4.3.x SDK. Are you using NETMF 4.3 QFE1 or 4.3 R2 Beta?

Sorry for the troubles; welcome to the community!

Chris

Hi KenTi,

I've been a .NET user for a long, long time, but I'm a newbie at Netduino and all that it entails... I'm excited about it's prospects, but having a really difficult time with it at the moment.

No worries. Let's help get you up and running here!

I'm unable to see any device when running NetduinoUpdate.exe. I have followed the instructions and installed all the pre-requisites. I'm able to compile and run the blinky demo.
...
I was able to get the update to work. Seriously, consider changing the name of the STDFU driver from amd64 to x64... I didn't touch it because I'm not using an AMD. ;-)

Okay, well, looks like you're already up and running with NetduinoUpdate. Awesome. Let's deal with the second issue...getting you up and running with Wi-Fi.

I tried to access the Wi-Fi, but failed miserably. It doesn't appear that Netduino 3 specific libraries are available. Even the download page http://www.netduino.com/downloads/doesn't point to 4.3.1 SDK, so how will I know when there's a new release?

Finding code samples is a bear... For Wi-Fi, all I see is something like https://msdn.microso...e/gg232761.aspxwhich almost helps, but doesn't actually have info on how to access the device itself (in the code sample, it says "WiFi.Enable...etc..." so I'm assuming WiFi is a reference to the hardware which I can't seem to find in the libraries of the SDK.

To use Wi-Fi, you'll want to set your network SSID/passphrase in MFDeploy. Then simply write normal .NET code (using Socket, HttpWebRequest, SslStream, etc.) and things should "just work."

On MFDeploy... Run MFDeploy.exe (which comes with the .NET Micro Framework SDK). Then change the transport from SerialPort/COM to USB so that your Netduino is selected. Go to the Target menu > Configuration > Network Configuration. Change the SSID and passphrase. When your Netduino reboots and your app starts running, the ACT LED should change to yellow (searching/connecting) and then green (connected).

Then...just write .NET code to use the network. No special Wi-Fi classes required.

Two more pointers:
1. Grab the new Netduino 4.3.2.1 SDK from the downloads page. The 4.3.1 SDK you're using will work fine--but the new SDK includes the new universal Netduino template and GoBus goodies.
2. Netduinos boot faster than Wi-Fi can connect sometimes. Be sure to wait for an IP address before trying to connect to the network (or you'll get a SocketException since you don't have connectivity). Here are two options for that:

while (IPAddress.GetDefaultLocalAddress() == IPAddress.Any) ; // wait for DHCP-allocated IP address

...or if you'd like something event-driven, capture the appropriate event...

Microsoft.SPOT.Net.NetworkInformation.NetworkChange.NetworkAddressChanged += NetworkChange_NetworkAddressChanged;

even tried writing a simple text file to the SD card, and got the file there, but even doing a .Flush() fails to write the contents... again, I can't find any samples specific to the Netduino 3.

Let's handle that separately. First of all: are you using a <=2GB MicroSD card (not SDHC)? The SD driver is part of the NETMF core, so we can do some investigation and then run this up the ladder if there's a bug.

Chris

Hi KenTi,

You Rock!!! Thank you soooo much for your fast reply and on a Saturday as well!!... I love my green light ;-)

We're not always here on the weekend, but we're here for you And actually there's a community of awesome people here supporting each other--so it's really them that deserve all the thanks.

Was there docs somewhere that I missed on that? What if I wanted to read the SSID from, say, from a config.txt file from the SD card and dynamically configure it.. is that way to in depth at this point in time? When I try to Wireless80211.SaveConfiguration, I get a feature not supported type error...

There are some flash wear concerns with changing SSIDs all the time so we haven't enabled dynamic changes to SSIDs...although that's something we could possibly patch into the old SPOT libraries (Wireless80211.SaveConfiguration, etc.) if critical to your application. For now I recommend using MFDeploy... And looking forward to all the new API goodness coming in NETMF 4.4 and beyond.

As far as SD card, I purchased the one I think you recommended from Amazon... 2GB Micro SD.

I wrote some simple code based on what I found on the net and it basically wrote to \SD\TestFile.txt using File.WriteBytes

This came from http://forums.netdui...ile-to-sd-card/which seemed to also have the same issue about it not committing the text to the file.

Ah yes, looks like this might be a bug in the NETMF core. Can you add your experiences to that thread, and I'll ping the team in Redmond to see if this is something that can get fixed in NETMF 4.4? [Also, do any of the workarounds in that thread fix things for you?]

Chris

A quick update on Netduino.IP...

The Microchip ENC28J60 chip that we use on Netduino Plus 2 is tried-and-true. But it's also tried-in-true as in a "last decade's technology" kind of way.

We have found an awesome new SPI-based networking chip for the next generation of Netduino hardware. Please allow me to introduce the Asix AX88796C.
http://www.asix.com....ail&PItemID=104

This networking chip has PC-class features. It is high performance and low power (including power management features). It supports both 10mbps and 100mbps, auto-crossover, wake on LAN and more.

In a nutshell, it is one awesome networking chip.

So of course, we have built a Netduino.IP link layer driver for this chip. 100% managed code. And that driver code is now checked into the Netduino.IP repo at GitHub.

https://github.com/n...Layers.AX88796C

Chris

That would be Netduino...

Official announcement coming shortly.

Here's a big hint:
http://www.amazon.co...=A15S1YSPRYIXOQ

Hi Sukasa,

Wake-On-Lan...  will that factor into the capabilities of the N+3 natively, or is that not likely?

What would you like WOL to do on the board? It's already in a pretty low power mode normally. Would you like the board to go into a deeper sleep--and then wake up when WOL is received? Or trigger code via an event, etc.?

P.S. The next-gen Netduino Plus board is called Netduino 3 Ethernet. Announcement coming soon, in stock on 30-Jun-2015.

Chris

That's interesting, on the cc3100 boosterpack, one need an extra board to upgrade firmware, but on this board one doesn't need that?

Nope, you're good to go. On Netduino 3 Wi-Fi, we actually wired up both SPI and UART to the CC3100. We have power management, reset support, and more. And of course your MFDeploy network config settings just work.

When we build platforms, we tend to be thorough; we believe in building high-quality, well-engineered gear.

Chris

Over the years we have received a lot of requests for Wi-Fi support.

So this last year we have been working with Texas Instruments to natively support their new world-class Wi-Fi networking chip, the CC3100.
http://www.ti.com/ww...-fi/cc3100.html

[Yes, there is some new hardware being announced shortly, featuring this chip.]

We have built a hybrid Netduino.IP stack for the TI CC3100 Wi-Fi chip, integrated into System.Net.Sockets. And SslStream (yes, it supports SSL/TLS 1.2 as well).

Source code be found here:
https://github.com/n...duino.IP_CC3100

We will be assimilating this code back into the Netduino.IP core over time. For now, because we will need to update and enhance the special hybrid build, we have created it as a distinct repository.

Chris

Hi xmen,

This is just amazing. Built-in WiFi support exactly what I wanted. Lots of questions and feature requests. But most important is can gobus ports allow to have more IO pins ?

As Nevyn alluded: yes

One caveat: we're moving very rapidly from GoBus 1.0 to 1.5, so the initial release of the 4.3.2 firmware (beta 1 for Netduino Go, 4.3.2 for other boards) does not support the virtual I/O features of Shield Base (beta). We will be pulling back in support for that virtual I/O shortly as we finish a few more tests.

Chris

One more cool thing... The CC3100 driver even has the ability to upgrade the CC3100 chip to the latest firmware

We actually do this on the production line (for Netduino 3 Wi-Fi), and firmware upgrades can happen manually or automatically in-field as well.

Here is a quick snapshot from the reflashing procedure (from the Output window).

*** Version info before upgrade ***
ChipID: 0x4000000
fwVersion: 1.2.0.2
phyVersion: 1.0.3.23
nwpVersion: 2.2.0.1
romVersion: 13107

Creating service pack file.
Writing service pack at offset: 0
Writing service pack at offset: 1024
Writing service pack at offset: 2048
Writing service pack at offset: 3072
Writing service pack at offset: 4096
Writing service pack at offset: 5120
Writing service pack at offset: 6144
Writing service pack at offset: 7168
Writing service pack at offset: 8192
Writing service pack at offset: 9216
Closing service pack file.
Service pack successfully written.

*** Version info after upgrade ***
fwVersion: 1.3.0.1

If you want to verify the Wi-Fi firmware on your board is up to date, you can actually call into the upgrade function via reflection like this:

Type.GetType("Netduino.IP.LinkLayers.CC3100SocketNative, Netduino.IP.LinkLayers.CC3100").GetMethod("UpgradeFirmware", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Static).Invoke(null, new object[] { });

Since we can automatically upgrade CC3100 firmware in code (during radio initialization) there's no technical reason you need to do this manually...but I thought you guys would enjoy this deeper detail.

Chris

Hi Joshk,

I just spotted the new design.  Very cool.  But will this thing have access-point capabilities?  I don't have a router where I use mine, I need to tablet to connect TO the Netduino.

The driver is set up to use the CC3100 chip in station mode, but the CC3100 does support being an access point for one device. It would take a few hours to tweak the firmware to your liking to enable AP functionality, and if it's a heavily-requested feature we could make that an officially-supported option as well.
[ All the source is here: enjoy the freedom of open source ]

Chris

Hi xmen,

For me, I need AP functionality more. It would be nice, if we can initialize the WiFi with its settings, either be an AP or connect to a router without changing the firmware. Please do add option for it.

Noted. If we enabled the AP feature as an option in the root Netduino 3 Wi-Fi firmware, it would be an AP for one device (so you could easily connect a device _to_ the Netduino 3 Wi-Fi). Would that be super-interesting to a lot of you?

Also, is it possible to use "STM32F4 Discovery" chip in Netduino 3 ? That would be just awesome. Please take a look once.

Even better: we're using the brand new STM32F427VI Rev 3 chip from ST on Netduino 3 Wi-Fi. With 2MB flash (dual-bank) and 256KB RAM. http://www.netduino.com/netduino3wifi/

Chris

P.S. If you don't see your mainboard in Netduino Update, switch it into bootloader mode using the following instructions:

• Press the pushbutton on your Netduino mainboard.
• Hold the pushbutton while powering up your Netduino via your computer's USB port.

P.P.S. If you are concerned about having a permanent MAC address stored in OTP flash, simply set it to all-zeroes. Write-once flash works by flipping bits from 1 to 0 (i.e. erasing bits).

Netduino Update makes upgrading mainboards a breeze. But until now we've still had to re-enter the board's MAC address in MFDeploy after the upgrade.

No more. The newest firmware (4.3.2.1+) for Netduino Plus 2 and Netduino 3 does away with this extra step: the firmware now automatically retrieves the default MAC address from write-once flash.

A few notes:

• Netduino 3 Wi-Fi mainboards were already pre-programmed with a default MAC address.
• The default MAC address is written into write-once flash, but can still be changed once or twice.
• The current MAC address can be updated at any time using MFDeploy's Network Configuration. Reflashing later on will reload the permanently-stored default MAC address.

Here is a quick tutorial on how to permanently set the default MAC address in your Netduino Plus 2 board.

Step 1: Select your Netduino in Netduino Update; click Options...



Step 2: In the options dialog, switch to the new Network tab.



Step 3: Enter the default MAC address for your board (from the sticker on the back of your board).



Step 4: Close the options dialog to save your board's MAC address.


That's it! If you reflash your board and open up MFDeploy's Network Config dialog, you will see that your MAC address is reloaded automatically!

Please let us know your feedback/experiences with this new feature,

Chris

Hi cabodcam,

9V batteries drain pretty quickly. Does this occur when the battery is brand new?

Here's a sample datasheet for an Energizer 9V battery. They'll handle higher current drain (up to 500mA in the datasheet), but they're really best used at lower current drains.
http://data.energizer.com/PDFs/522.pdf

Have you tried using a battery pack of 6 AAs? DC power is DC power, so as long as the power source supports the voltage and number of mA that your project uses...it should work the same on battery or mains (AC adapter) power.

Welcome to the Netduino community,

Chris

Hey Tim,

If the timer overflows at the point marked, then the overflow (carry) has been missed but the timer has wrapped back to 0, so that would result in time _going backwards_ at which point HAL_COMPLETION::DequeueAndExec() will not be able to schedule any further events until the timer overflows again.

Sleuthing Awesome.

NETMF uses MachineTicks for all timer/thread scheduling (which is based off of the overflow bits added to the core timer bits. There's always a possibility of a bug in the timing code--but other bug scenarios are a lot more likely. We beat up on timer code quite a bit.

Chris

Hey Tim,

It uses Thread.Sleep in the broadcast loop

The broadcast loop is on its own thread, right? Not blocking a managed event from finishing its processing?

I have Microsoft's Network Monitor which is a lot like WireShark. I'm not sure how I can capture traffic from the Netduino to the router though, as it all goes through a switch. I would see the broadcasts of course, but I suspect none of the 'direct' traffic. I'll investigate whether there is something I can do with SysLog on the router.

You'll want Wireshark. It's awesome. And then in the toolbar, add the filter "eth.dst == 5c:86:4a:xx:xx:xx || eth.src == 5c:86:4a:xx:xx:xx" where xx:xx:xx is the rest of the MAC address on your Netduino. If you want to see broadcast traffic too, add "|| eth.dst == ff:ff:ff:ff:ff:ff".

One question. Would socket.Accept() ever time out and return without there being an incoming connection?

I don't believe that socket.Accept() should timeout unless the socket is closed/disposed. But if you're seeing different behavior (and it's inconsistent with the desktop implementation) we can tweak the behavior to match expectations.

P.S. I'd be happy to share the code if you think it will help.

Let's see if we can provide enough info that you can track down the issue on your side...and if we run into a brick wall this might be a good option for deep debug. Let's try to get it to fail quicker (or 100% consistently) first though...unfortunately intermittent non-reproducible issues can't get quick resolutions. [It sounds like this is reproducible though...which is great!]

Thanks Tim!

Chris

Hey Tim,

Accept-deadlock.PNG

So the good news here is that it appears that the stack is not locking up the board (unlike issues we had with lwIP). The bad news is that there is some weird blocking issue going on.

My first two guesses:
1. NETMF tends to execute one managed hardware event handler at a time, queued, in series. If a project has code in a managed event handler which is not exiting and which is blocking the network stack from getting interrupts...you can see this kind of behavior. This is one of the tradeoffs of the NETMF threading model. [Side note: we are working on some concepts that would actually improve NETMF in this area without breaking backwards code compatibility. But nothing shipping today.]
2. A core runtime bug. If we can reproduce the bug in managed code, and we can whittle down the sample code to a manageable size, we can debug the native issue and work with Microsoft to remedy it in the NETMF core.

Can you send me a copy of the source, along with repro instructions on how to repro the issue consistently? And also your board type, firmware version, etc.? We'll repro the issue here and work with you to resolve the issue (either through guidance on how to modify the sample or through a core bugfix).

Thanks so much for all your effort testing out the new bits!

Chris

Hey Tim,

Do you have Wireshark, and either an old-fashioned hub or a switch/router which will copy all packets to all ports? The easiest way to debug the networking traffic-on-the-wire side of this is by using Wireshark.

Is there any special action you take based on packets received after the start of a new hour? Extra threads (or blocking threads) that happen on that hour marker? Networking does live at the managed code layer--so if there's a blocked thread within an event handler...NETMF may not be so happy to let network traffic through.

This is a very curious issue, very interesting. Let's figure it out.

Chris

Hey Tim,

After I've spent what amounts to several days digging into this issue, it would be nice to know that someone is at least reading these threads...

We're definitely here, following along. Just trying to get a handle on what is going on behind the scenes. This post was really helpful. See below. And thanks for all your test time!

Digging a bit deeper, when the network stack is frozen, I have several threads all stuck in WaitHandle.WaitOne(), backtracking up the call stack shows that the calls originated as follows:

• Main thread - TcpSocket.Accept
• ILinkLayer.SendFrame
• ArpResolver.SendArpGenericThread
• IpV4Layer.LoopbackInBackgroundThread
• ICMPv4Handler.SendIcmpMessagesThread
• DHCPv4Client.DhcpStateMachine
• EthernetInterface.Send
• TcpSocket.TcpStateMachine

Okay, now this is interesting. This is your _stack trace_??? Can you grab a screen capture of this? DHCP and ICMP shouldn't really be involved at all with a TCP packet send...

This scenario really feels like a "NETMF event queue is being blocked" kind of issue... Let's drill into your code sample and figure out what's up.

Thanks Tim,

Chris