Hi Frode,

   I can't speak to any other version except the Netduino 3 as it's all that I have. With the Netduino 3, this worked just fine with the MPL3115A2 that's on the SparkFun WeatherShield.

   That said, if you don't have repeated start bit support, doing a read will start reading from byte 0 of the registers. So you can get all of the registers and just grab the bytes you want out of the array. Icky, I know, but it should work from what I saw.

It seems that if System.Security (from .NET MF) is added to a project and then deployed to my Netduino 3, the entire device crashes and burns. It becomes completely unresponsive and I am left with no option but to flash the device. It doesn't matter if you are actually using the assembly; just having it in the references will crash the Netduino, even if nothing from the assembly is even used. Once the reference is removed, everything is fine.

When deploying/debugging with Visual Studio, the debugger halts as it tries to load the symbols for System.Security. But even if the debugger is not attached, the Netduino just dies.

I have reproduced this with a very simple project that simply flashes the LED.

I have noticed that System.Security does not appear to be in the firmware for 4.2.2.2, even though Visual Studio marks "Copy Local" as false. Setting "Copy Local" to true doesn't help because then VS says that it can't find %ProgramFiles(x86)%\Microsoft .NET Micros Framework\v4.3\Assemblies\le\LE\System.Security.pe ... which doesn't exist at that location although it is in the Assemblies\le folder. Creating this folder and moving the files there so VS will happily try to deploy does not fix anything.

Any ideas on why this is happening?

Right now, there's nothing that I really need in this assembly but since it kept me up until the wee hours of the morning last night, I'm really curious if anyone has any ideas on what's going on.

OK ... ran through the process with the defaults and ... IT WORKED!!! Yay! Thanks!

One strange thing, though ... the Dfu File Manager only seemed to want to save to its installation folder (Program File (x86)), not to the folder that I specified for the files. This baffled me a bit as it reported success but there weren't any actual files until I ran it "As Administrator".

One question ... when running the "DFU File Manager", there are some additional inputs. Under "Device", there's "Vendor ID", "Product ID" and "Version". Also, under "Injection" is "Target Id" and "Target Name". Should these be left as they are or do they need to have specific values?

So ... what's the backup plan?

I'm currently in this pickle and the Netduino update app a) doesn't recognize the device as a Netduino (it says "STM Device in DFU Mode") and when I do select Netduino 3 Wi Fi from the options, the app either hangs (on 2 machines) or says something along the lines of "Could not save configuration. Error: Specified method is not supported" (on a 3rd machine).

I had already updated to 4.3.2.2 when suddenly, in the middle of a deployment, it just stopped behaving nicely. :-(

I got this working by sending the Write and Read in as an array within a single I2CTransaction.

Like this:

Works like a charm with the SparkFun Weather Shield's MPL3115A2. See details and source on my blog at http://blog.devbiker...to-the-Netduino.

Your code on the device needs to do something with the network. Even if it's as simple as GetIsNetworkAvailable().

Drove me crazy for a bit as well.