Well, found the issue.  Wouldn't have believed it.

USB port on computer.  Switched the port and now 4.2 works and 4.3 works.  I think it was in a USB 3.0 connector.  

Okay, so I install Windows XP SP3 32-bit on VMware Workstation (clean install), install Visual Studio 2010 C# Express, netduino sdk 4.2, and MF 4.2.

Attach my Netduino to the XP VM machine.

Had a known issue with MPP, fixed (didn't install .NET 2, just did the updated manifest).

My blinky builds and deploys, but no love in attaching a debugger.....   

What could it be?

I might have to go all the way back to MF 4.1.

I'm sure I've done that at least once.   I did verify that all the references match desired SDK version by using the Properties window.  And they all point to the appropriate locations where everything is installed ( which is all default locations ).

The thing is, I did a blinky and it deploys, works, etc.  I would think that a mismatched assembly would just lock it up.

The draw to using NetDuino was the integrated debugging.  Might as well go back to MPLAB and doing it on a PIC board, at least there the ICD3 debugger works (fingers crossed, it has been a few months since I've used that, too).

Okay, so I  pull out my NetDuino 2 Plus because I need to test some breakout boards via SPI.  Ideal situation, rapid code writing, good testing.

First I upgrade everything to VS2013, firmware, sdk, MF.NET to 4.3.  Got the problem that is the topic of this post.

After a day fighting with it, I decide, "Okay, downgrade, everything used to work....". 

Now, I'm at VS 2010 with MF 4.2, sdk 4.2, firmware 4.2.2.  Still get the same error message.

Steps taken include using NetDuino Update to erase the app image, DFSU (or whatever it's called) works ( I had to reflash to 4.2 with that), NetDuino Update works ( I had to flash to 4.3 with that).....

I'm back on MF 4.2 and Visual Studio 2010. 

I confirmed that my USB driver is from Secret Labs and has the appropriate version number (4.2) for now.

Any suggestions?  Anybody knows what's wrong?

baxter,

which binary did you use for the eLua download into Netduino?  Or did they remove it?  I see one for an Atmel based Netduino, but none for the STMicro STM32F4?

--Ken

Help. 

Using Netduino Plus 2.

Okay, I got Visual Studio 2013 and Visual Studio 2013 Express for Desktops.  I managed to get everything installed.  Updated the firmware with the Netduino update.  Everything looks okay.

Project builds and deploys, but when I want to debug, it reboots the Netduino, and then tries to re-attach the debugger.  It fails.  Subsequent attempts to deploy fails.  Need to remove/insert USB wait for it to detect and I can deploy again, but the same error happens when I try to debug.

I erased the app (using the Netduino Update options dialog), but it doesn't make any difference.

Just to be clear, the MF experimental is no longer needed, right?  CodePlex has the MF 4.3 - R2-Beta which supports Visual Studio 2013.  But what about the Netduino SDK ? Do we use the experimental version as linked in the beginning of this forum?

-------------

The bug is me, doing stupid things...

Actually, I'm fiddling with the A2D.  For some reason, I can only change the acquisition resolution on the first pin.  Well, I accidently deadlocked the Read.....

Is there some way to debug the HAL?

--Ken

Well, I've got a pretty darn repeatable BSOD situation.  I remember earlier reading that they wished they could get a repeatable case.

Essentially it occurred when I deadlocked the STM in the HAL layer while debugging or attached via MFDeploy.  First, the system disconnects me saying it lost connection.  Then Netduino is dead.  I push-button restart it, and BLAMO - the BSOD.

I could probably tighten up the steps a bit, but a) my computer doesn't like the BSOD, it takes a reeaaaalllly long time to stabilize after rebooting, c) I keep losing points on my "system reliability", d) I'm afraid the WER is gonna tattle to Microsoft and they will revoke my Operating System license.

--Ken

Well only that I've got 4.6 working.

I don't want to go to the 4.3 firmware yet, as I'm using VS2010.

Now, should I be using 4.7.2?

I had major pains getting the firmware built.  Of course, the problem was a flakey usb port.  But to go through another iteration of "it don't work" trial an error is not something I want to do.

Okay, excuse my blasphemy, but I'm investigating putting FreeOS (or similar) on my Netduino and building a native app.  Yes, this would be a lot of work.....

The way this came about was a need to create/test/build a new STM32 based board.  I took stock of what I had laying around and noticed that the Netduino Plus 2 that I have fits the bill perfectly (well, almost).

What I like is there is not a lot of extra junk on the board (accelerometer, LED's, POT's, Kitchen Sinks, etc).  However, I don't want to totally toast the board from running the base MicroFramework.

I however, need to understand a few things about flashing.  First, I can DFUSE stuff and I can MFDeploy stuff successfully.  I've built firmware and used MFDeploy to push "BuildOutputTHUMB2GCC4.6leFLASHreleaseNetduinoPlus2bintinyclr.hex" 

What I need to understand are the underlying bits - what does DFUSE connect to?  I presume the BootLoader.  Does STM have their own bootloader?  What does MFDeploy connect to? 

And most importantly --- what should I NOT do, to keep everything running?  Ideally, I want to move from a Native STM app to a MicroFramework app and back.

I'm okay with reading docs, if someone can point me to something that is pertinent.  I don't want to start reading the STM FLASH programming guide and then realize that "Oh, Netduino does something a bit different....." after I totally brick my board, have to solder in the JTAG connector headers and buy the STLink cable.

Thanks Mark. 

Little did I know that amount of stress and stupidity I would apply to the problem.

Long story short, my USB cable to the Netduino was flakey and would only work intermittently.  I changed cables and ports and all is well.

However stupidity kicked in:

I made sure I got the correct Yagarto, being very careful to browse to the "older" version.  However, SourceForge in it's infinite wisdom ensure that the "current" version is listed first and highlighted - so I got the wrong gcc build, which totally occupied several hours of my day trying to figure out why it didn't work.

My first flash didn't work and I was sure I bricked the board.  I was soo afraid of doing that.  However, once I knew that the board was not working, it sorta relieved my stress for trying different things.

DfuSe Demonostrator constantly crashes (mostly when doing 'reads', and I was using 3.03.  However, when trying to downgrade to the 3.02, it wouldn't work at all.  So, now I'm back to the 3.03.

I pulled the 4.2.2.2 DFU and tried to flash that.  It would sometimes work and be seen by MFDeploy, but rarely twice in a row.  After my first successful operation with MFDeploy, it would not reconnect for anything.  I would have to either reflash, reboot, or un-plug/re-plug.

Finally, decided to change USB cables, the computer port and also remove all other USB devices ( I had two phones charging as well ).

Then, and only then I started to have success.

I've managed to reduce the precision of the analog line from 12 to 6 (or so .NET reports it as such)  But seeing the same time latencies.  I'll have to work at it a bit.  I'm probably going to do a lot of work on the analog channels - and do a bunch of reading.

But, it is nice to know I can change the firmware a bit, by actually having done it, as opposed to reading that it can be done.

However, here's a question:  Is there any place to commit changes?

I was wondering if a cheap oscope could be made from the Netduino+2 that I have. 

From my understanding at looking at the code, the AnalogPort read function blocks until it finishes acquisition in the full 12-bit mode.  I've timed this to roughly 70us per read which would only give me a less than 14Khz frequency, if I only used 1 channel.

The ST manual indicates that a smaller resolution would reduce the read time and that a continuous read is possible.

Would if be feasible to modify the Firmware 4.2.2 to a) reduce the analog precision, make the analog precision variable, and/or c) support a continuous read capability?

I'm new to ST (and ARM) but I think I could have a go at it.

Is there a good way to compile the firmware on a Win7 box?

 

 If so,i can port it from my board to Netduino,and here's the sample code how to use the CAN bus in .Net Micro Framework.

 

 

 

I'm interested.  Let me know.  I'm still on the 4.2.2 firmware, would it just be a patch to that?