Howie Goodell

Hey, thanks again buddy!

I was able to resolve the problem -- all Visual Studio and Secret Labs nonsense.  Once I'd resolved the problems using the official download, then I reloaded the firmware I had built 2 days ago using your additions and procedure.  It compiles and debugs a blinky just fine.   I posted the details here, because it sounded like they were having related problems.

I'll let you know if I see any problem with low-level serial port access (the main reason I needed interop) or network.  Otherwise I don't see any more roadblocks.  Whew!

Yes, I plan to do JTAG debugging soon; so please send me anything convenient.  I'll be glad to do some writeups, etc. on them if you don't have time; this was a big help to me.

Take care!

Howie

Edit#3     BLINKY LIVES !!!!

When I purged the broken (Release 4.1) SecretLabs libraries that I had somehow acquired, Blinky works including single-stepping from MSVC.  This is running on firmware compiled from the 4.2.1 source using the free GCC compiler (instead of the $5000 one-computer-only RVDS one) following these instructions ( posts for context ) from ziggurat29 (monster thanks again, buddy!).

Details:

Initially I wasn't able to get any of the SecretLabs assemblies to load except the diagnostic (it complained there was no SecretLabs.NETMF.Hardware; so it refused the SecretLabs.NETMF.Hardware.Netduino DLL I'd imported -- huh?).  So I dumped them, spent a couple minutes with the board schematic and blinked 

Microsoft.SPOT.Hardware.Cpu.Pin.GPIO_Pin10 instead of SecretLabs.NETMF.Hardware.Netduino.Pins.ONBOARD_LED

It worked fine!  Then I switched back to the compiled source (I was debugging with the official download firmware once I realized that had the problem too after I tried to switch back to 4.2 QFE1 SDK and Porting Kit and Netduino SDK) and verified that worked.  Finally, I tried switching to the SecretLabs ONBOARD_LED, and that worked, too.

While Visual Studio 10 was linking, I noticed a message saying it was downloading SecretLabs.NETMF something -- presumably that's why it worked.  That reminded me that I'd seen that message flash up when I first ran MSVS10 after switching back to QFE1.  I'm wondering if that's where my 4.1 SecretLabs assemblies came from that have been messing me up the last day or so.

At a programming conference long ago I met a programmer who had named his business "Abracadabra Typesetting" to be first in the Yellow Pages listing (I told you it was long ago).  He'd discovered that name was a big mistake: customers told him it made them afraid his business might go "Poof!".  These automagical downloads are charming when they just work, but now every time I see it, I'll worry what might have broken.  At least give us a way to know what was downloaded if we miss the 5-second popup.

Anyway: all's well that ends well.  I can finally make the firmware changes and give my boss what he is clamoring for (just not eager-to-buy-a-$5000-tool-for-what-should-have-been-a-small-project clamoring).  I suspect we aren't the only ones who'll be very happy about this capability.

Howie

==============  OLDER, FOR BACKGROUND ONLY  =====================

Edit#2: In trying to go back to 4.2 QFE1, I clearly have gotten some Netduino 4.1 assemblies somehow.  The version of Microsoft.SPOT.Hardware that two of them ask for (4.1.2821.0) is the exact version in my 4.1 assembly.  I am trying to get the SecretLabs 4.2 references to link properly instead of the 4.1.  Then I should be developing on top of an interop-ready system using the free GCC compiler; yah!

Edit #1

Hi --

I'm having a related problem.  After uninstalling the QFE2 SDK and PK and installing 4.2 QFE1 versions, a Blinky project created in my MS Visual Studio 10 downloads but refuses to run, not only on the GCC-compiled version that I built following ziggurat29's procedure here , but even on the stock 12/3/2012 firmware download (NetduinoPlus2_Firmware_4.2.1.2.dfu).  Visual Studio apparently is still looking for the wrong version of modules: Debug output at the end of this.  

Chris, I think somewhere you mentioned unzipping an update over SecretLabs SDK Visual Studio sources.  Can that work in reverse, or do I need to uninstall and reinstall Secret Labs SDK VS?

Thanks!

Howie

================  Debug output on attempted download  ===================

(note cleaning and rebuilding got rid of these errors, but it still failed to initialize after the download)

Hi --

I'm still working through confusing errors trying to get a Visual Studio project to run.

(Removed this, because I just found similar problems with the official download.  So it's apparently some mis-configuration of MSVS10 when I went back to QF1.  Will pursue -- sorry for crying wolf again.  Problem is: if I investigate for hours to be sure, I may be missing something that would be obvious to someone else.)

(Keeping this, because inquiring minds want to know):

Dave,

Fortunately I'm a harmless idiot.  I rechecked everything and found that I had copied the wrong block of the release version into the TinyBooter slot.  As you diagnose, failure to return anything to the ping points straight at the boot code.  With the correct version, it pings TinyCLR.  Excellent!

I am trying to get MSVS 10 to deploy now; may be back with a question or two about configuration or setting up hardware debug shortly.  However, I am seeing how much work  you did to get this toolchain running, and I really appreciate it.  I think the price point and free-as-in-speech nature of GCC will open up interop on this board to a lot more people.  

Thanks!

Howie

I'm concerned about the two compile errors, should should be none (unless they are 'can't include file xxx' because of the version number issue)

FYI Dave, changing the YAGARTO version didn't fix it, but the change to set_base_env.cmd did.  I now get 20 warnings and no errors, same as you.  Yippee!  And thanks a bunch for your hard work!

Now to see if it boots....

Howie

Hmmn -- I made a DFU image following the wiki instructions, but it doesn't ping in MFDeploy.  Reflashing the release one (from wlhich I extracted TinyBooter) does.  What to do?

I have the ST-LINK/V2 dongle and adapter Chris recommended; verified I can see program memory and registers with JTAG ifc using STM's utility.  I also set up Eclipse and verified I could build a test ARM program; just have to get those together; good idea anyway.  Dave, I'll go look at your posts from earlier and start debugging this in hardware, unless you can suggest something obvious I might have missed here.  Anybody have ideas?

Thanks!

Howie