Hi Paolo,

It's a standard MiniJTAG port (Cortex Debug Port to be exact).

You can debug using the STLink/V2 and TI MDL-ADA2 JTAG to MiniJTAG adapter. $41.25 for the set, which is ridiculously inexpensive.

We use these instead of our $2000+ ARM RVICE hardware. It works beautifully and supports quite a few breakpoints. We debug C# code, step into native code (alt+tab) and back and forth. It's pretty awesome.

And for those who want a really really nice Cortex-M4F devboard for C/C++ code...Netduino Plus 2 does that really well too. Arduino shield compatibility is a big bonus there too.

Chris

Hi Chris,

All purchased and on my desk. However, there is a teensy problem. The mini JTAG cable Mouser sent us with the TI MDL-ADA2 JTAG to MiniJTAG adapter is female-to-female, but the mini-JTAG connection on the Netduino Plus 2 requires pins on the connector. Are your mini-JTAG connectors male-to-female, or are you doing something else you didn't mention in your post? Two possibilities:

• You bought a male-to-male mini-JTAG adapter.
• If the orientation of the pins works, you removed the RESET button from the mini-JTAG adapter and pushed its pins through the board with no cable.

Example of #1: in Mouser's "customers also purchased" box, I found a 20-pin male-to-male connector that might work sawed in half. Let us know!

Thanks!
Howie

Hi Paolo,

It's a standard MiniJTAG port (Cortex Debug Port to be exact).

You can debug using the STLink/V2 and TI MDL-ADA2 JTAG to MiniJTAG adapter. $41.25 for the set, which is ridiculously inexpensive.

We use these instead of our $2000+ ARM RVICE hardware. It works beautifully and supports quite a few breakpoints. We debug C# code, step into native code (alt+tab) and back and forth. It's pretty awesome.

And for those who want a really really nice Cortex-M4F devboard for C/C++ code...Netduino Plus 2 does that really well too. Arduino shield compatibility is a big bonus there too.

Chris

Hi Chris,

What's the IDE you are referring to that steps from C# in and out of native code? Is it IAR (that you mentioned in another post)? Their free "Kickstart Edition" is limited to 32 KB, which won't compile your platform.
(I was using MS Visual Studio 2010 for .NET MF C#, but I don't think that would support interop native code on ARM.)

Thanks!
Howie

Hi Paolo,

It's a standard MiniJTAG port (Cortex Debug Port to be exact).

You can debug using the STLink/V2 and TI MDL-ADA2 JTAG to MiniJTAG adapter. $41.25 for the set, which is ridiculously inexpensive.

We use these instead of our $2000+ ARM RVICE hardware. It works beautifully and supports quite a few breakpoints. We debug C# code, step into native code (alt+tab) and back and forth. It's pretty awesome.
...

Hi Chris:

What IDE are you describing here?

Thanks!
Howie

One more question: the source link on the Downloads page gives me 8/12 sources. Chris, for those who want to compile interop changes, where can we get the sources that correspond with Update 1 firmware? Thanks! Howie

Hi Chris,

I finally am trying to upgrade my Netduino plus to this version, after encountering various problems trying to compile and deploy the 4.1.0.6 firmware.

My goal in switching to the latest version was to make my mistakes where they would be more useful. It seems I am already succeeding.

When I ran the Atmel SAM-BA utility and looked for the TinyBooterDecompressor.bin file, it was already selected. Gullible me: I thought by un-installing all the 4.1 SDKs etc. and re-installing 4.2 versions, it had selected the new version. Nope -- it was showing me the 4.1 version I had compiled yesterday, deep in the hierarchy of the 4.1 Porting Kit output directories (which uninstalling doesn't remove). Turkey!

I flashed the new version downloaded with the 4.2.0.1 firmware using SAM-BA. Now I can deploy the firmware, and it pings -- TinyCLR. Yah!

Howie

Version: 4.2.0 Update 1 (version 4.2.0.1)

This firmware requires use of the .NET Micro Framework v4.2 SDK (QFE2) and Netduino 4.2.0.1 SDK.
...
To flash this firmware:
1. Detach your Netduino
2. Press and hold your Netduino's pushbutton while plugging it in via USB; this will put it in TinyBooter mode.
3. Flash TinyCLR using MFDeploy v4.2+
a. Click "Browse..." and select the TinyCLR files (ER_CONFIG and ER_FLASH).
b. Press "Deploy". It will take a few minutes to update your Netduino.
c. Detach and reattach your Netduino (power cycle)

...
Enjoy, and please let us know if you run into any troubles.

Chris

Hi Chris,

I finally am trying to upgrade my Netduino plus to this version, after encountering various problems trying to compile and deploy the 4.1.0.6 firmware. I installed TinyBooterDecompressor
http://wiki.netduino...ep-by-step.ashx
and tried 5x to download this firmware
NetduinoPlus_Firmware_4.2.0.1\tinyclr.hex\ER_FLASH and ER_CONFIG
following the instructions at
http://wiki.netduino...ep-by-step.ashx
Usually I first hit Erase for the Deployment and User Storage; once I also erased Firmware. Repeatedly disconnected and reconnected with the button down.

Each time, near the end of the progress bar to deploy ER_FLASH, I get a pop-up:
"Error: Unable to deploy to device"
Power cycle: comes back to Tiny Booter.

I didn't see exactly this problem in other forum posts. Anybody else have it?

Howie

<blockquote class="ipsBlockquote" data-author="Chris Walker" data-cid="41271" data-time="1355067270">Hi Dave,<br /> <br /> <br /> 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).<br /> <br /> Chris</blockquote> <p>Hi guys,</p> <p>&nbsp;</p> <p>Kind of sad, because one of the additions in QFE2 was GCC support :-( &nbsp;</p> <p>I am trying to build some small interop additions with GCC on N+2 (I used a 30-day RVDS trial to build the previous version on Netduino Plus, but that's expired). &nbsp;I will follow through ziggurat29's procedures (I see they were just updated yesterday); just wanted to know if there's a change to that one.</p> <p>&nbsp;</p> <p>Happy Monday!</p> <p>Howie</p>

Dave, many thanks for the clear instructions!

 

One little nit is that saying GCC4.6 or 4.7 returns a stupid error -- the script setenv_base.cmd has all the sophistication of a 1985 DOS script and throws me out if I say anything other than GCC 4.2:

 

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

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

I am really excited about getting my Netduino Plus 2. So I thought that in order to pass the insane long wait of 2 day shipping, that I would create a pinout reference sheet.
...

Great help -- thanks!

Two more minor points for the next revision:
* Ethernet is 10/100 Mbps
* You might want to say "available" or "free" by the flash and RAM sizes. (Flash has 384 KB free out of 1 MB total; RAM has 100 KB free out of 192 total.)

Thanks again!
Howie

Hi Howie,


No problem, we've posted it on the downloads page.

Enjoy!

Chris

Chris,
I just downloaded "netduino plus 2 firmware v4.2.1 source" at http://www.netduino.com/downloads/ . Thanks much!
Howie

Hi -- One more question now that the source is out: what IDEs do you suggest using? You mentioned one that lets you drop down from C# to C++ interop debugging -- that sounds very cool; is it expensive? Have a good weekend! Howie

Indeed awesome! Question: when do you expect to release the source code for the firmware? Happy to beta-test; about to order the JTAG ICE you suggest. IMHO a decent interop development environment will open a lot of embedded applications for this board; usually they need a few specific things to be fast and/or a little different than the generic functions. Howie Goodell

Hi Howie,

I'll make sure we get the source code posted this week. We're working on 4.2.1.1, so we'll have another source update around the end of next week.

Chris

Hi Chris,

I know you've had your hands full, but please do post the Netduino source when you can. I could care less about I2C ;-)

Thanks!
Howie

Hi Howie,

I'll make sure we get the source code posted this week. We're working on 4.2.1.1, so we'll have another source update around the end of next week.

Chris

Hi Chris,

Have you posted it? I don't see anything yet on the downloads page (Netduino firmware still has 10/9 for Solutions/NetduinoPlus. Just got my board; debug cables hopefully tomorrow. We Yanks have our Thanksgiving holiday this week; I was hoping to take it home and play after the turkey coma wears off ;-) .

Take care!
Howie

Hi Nak.

1. .Net Micro Framework SDK 4.1 (QFE1)
2. .Net Micro Framework Porting Kit 4.1 (QFE1)
3. ND+ Firmware 4.1.0.6
4. setenv_RVDS4.0.cmd c:\rvds
5. 1st compilation with error which cann't execute command \armcc.exe, which was corrected by deleting letter \ in C:\MicroFrameworkPK_v4_1\tools\targets\Microsoft.SPOT.System.RVDS.targets
6. "C:\MicroFrameworkPK_v4_1\DeviceCode\include\..\Initialization\MasterConfig.h", line 12: Error: #5: cannot open source input file "platform_selector.h": No such file or directory is error for my compilation.
above is also corrected with copying platform_selector.h to the C:\MicroFrameworkPK_v4_1\DeviceCode\include\..\Initialization.
7. Fuse the bootloader on Flash
8. Fuse the .net mf on Flash. No execution in deployment. Error.

Kevin.

Hi Kevin,

I am also trying to compile interop native code changes. Last week I tried to do something similar to what you describe: compile 4.1.0.6 firmware using ARM RVDS 4.1, with similar result: after download, the Netduino Plus was never recognized, and I needed to start again with hard reset and loading TinyBooterDecompressor.

Yesterday I gave up on 4.1 and upgraded to all 4.2 (MF SDK, Porting Kit, Netduino SDK and Netduino firmware). One point I noticed was that the 4.2 Micro Framework SDK "New behavior" includes:
6) Support for RVDS 4.1
-- lack of this support may explain our inability to generate a working configuration on SDK 4.1.

Now I can compile and deploy the Netduino 4.2 sources from the download page http://www.netduino.com/downloads/ . This is the procedure that worked for me; change to fit your config:

One-time upgrade:

• (Ensure you have an ARM compiler; I did the 1-month trial of ARM RVDS to avoid issues with code size initially. Note I let it compile at the default C:\Program Files; probably less problematic to use a directory with no spaces in the name. Also use your disk and not network card for the license -- my network config changed on my company laptop and the compiles stopped working; good chance of at least a day delay getting support from England.)
• Download and install/upgrade to the 4.2 environment as described in the pinned forum post http://forums.netdui...-v420-update-1/ .
• Download and deploy the new firmware on your Netduino Plus (or whatever) as described at http://wiki.netduino...ep-by-step.ashx -- just to verify the precompiled 4.2 has no issues before you try your own version.
• For Interop, you also need to download and install the 4.2 Porting Kit (under "Other Available Downloads" at http://netmf.codeple...ases/view/91594 )
• (Optional: source-control the directory to keep track of SecretLabs and your changes. In my case, git init, git add *, git commit -m"Initial download" -- available at http://git-scm.com/downloads .)
• Download and unzip the Netduino 4.2 sources from the download page http://www.netduino.com/downloads/ . Copy to the root of the 4.2 Porting Kit; i.e. C:\MicroFrameworkPK_v4_2\ and overwrite all conflicts. (See why I wanted version control?)
• From a command window (I ran as admin; not sure if needed), initialize your msbuild by typing:
• setenv_rvds.cmd 4.1 "C:\Program Files\ARM"
• msbuild dotNetMF.proj >logs\dotNetMF.log

(Note I created a "logs" directory and do all my output to log files there -- consider doing the same unless you are a
very fast reader
Every time:

• setenv_rvds.cmd 4.1 "C:\Program Files\ARM"
• msbuild solutions\NetduinoPlus\dotnetmf.proj /p:flavor=release;tcp_ip_stack=lwip /t:rebuild >logs\np20121010_1.log
• View output to ensure no errors -- I use Chrome: file:///C:/MicroFrameworkPK_v4_2/logs/np20121010_1.log
• Restart N+ into TinyBooter (reconnect USB/power while holding button down)
• Start MFDeploy and follow the instructions at http://wiki.netduino...ep-by-step.ashx to deploy the two hex files created by your compile from the Platform Kit output directory: in my case C:\MicroFrameworkPK_v4_2\BuildOutput\THUMB\RVDS4.1\le\FLASH\release\NetduinoPlus\bin\tinyclr.hex
• Unplug and reconnect the Netduino and view the config with MFDeploy.
• Close MFDeploy and open Visual Studio etc. to verify your C# projects compile.

Let me know if these work; I'll make a wiki page soon.

Two requests for whoever can:

• SecretLabs post 4.2.0.1 source.
• Explain how to ensure that our interop project gets flashed as part of Solutions\NetduinoPlus, OR how to do an incremental download we can access using what look like new options in MF 4.2. Last year, Chris Walker suggested this old post from Ardeneo: http://adeneo-embedd...-framework.html -- it says to create your own Solution -- I'm fuzzy on how that gets downloaded.

Thanks!
Howie

Hi Chris, Thanks for the good suggestion, and also for the friendly welcome -- I'm looking forward to doing some good work with this cool platform. Unfortunately however, it seems that it throws exactly the same exception at exactly the same point for COM2 as for COM1. I attach an image of the debug window in case it gives clues. Probably the driver doesn't support this feature of the AT91SAM7X USARTs. I assume the next step is writing my own unmanaged code to interact with this? Since I'm new to this environment, any tips for this (or any other approach) would be most welcome. Thanks again! Howie

Hi Howie,

COM1 is a special "debug UART" which can only handle 8 data bits if I remember correctly.

Can you try COM2? Looking at the data sheet, it can handle 9 data bits.

Welcome to the Netduino community,

Chris

Hmm, it could also be the requested baud rate...or the combination of even parity with 9 data bits.

The USART code for Netduino Plus is in:
C:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\AT91\DeviceCode\AT91_USART

If it's a setting that the microcontroller can support and we don't support it yet, that's something we can also address in an update. [Or if you make the change, please consider contributing it--and everyone can have the update.]

Chris

Hi Chris,

Here's where the exception comes from in the 4.1 code (that matches the firmware I still have on the board):

C:\MicroFrameworkPK_v4_1\DeviceCode\Targets\Native\AT91\DeviceCode\AT91_USART\ATI91_USART.cpp
in the function AT91_USART_Driver::Initialize (the version finally called by the code in the folder you mentioned in the case of the Netduino Plus's AT91 processor):

Lines 98-115:
switch(DataBits)
{
case 5:
USMR |= AT91_USART::US_CHRL_5_BITS;
break;
case 6:
USMR |= AT91_USART::US_CHRL_6_BITS;
break;
case 7:
USMR |= AT91_USART::US_CHRL_7_BITS;
break;
default: // not supported
fRet = FALSE;
//fall through for default
case 8:
USMR |= AT91_USART::US_CHRL_8_BITS;
break;
}

9 data bits will hit the default: case and return false, generating the exception I saw.

I will test a modified Initialize and also add functions to set the 9th bit for certain characters, etc., and contribute them back for anybody else who has similar requirements.

BTW, have you created a solution for loading unmanaged code at runtime as you suggested in this 2010-2011-2012 thread? http://forums.netdui...28-native-code/

Thanks much!
Howie

Hi --

Just a minor point: trying to compile 4.1 firmware using the ARM RVDS compiler -- by coincidence that's also version 4.1. Unfortunately, the set_context scripts only support RVDS4.0. Here's an attempt to add an RVDS4.1 target, but I'm not sure it's correct. The compile is still giving errors that could relate to incorrect variables OR to the fact I let ARM install to Program Files -- the quotes may be what's screwing up the batch files. Chris, any suggestions? As I promised about the serial, I'll add a wiki page explaining this -- once it's working for me.

Notes about setconf_base.cmd:

• Comparing labels :SET_RVDS_V40_VARS and my new :SET_RVDS_V41_VARS, notice my environment has ARMCC41BIN/INC/LIB set, where the 4.0 version sets RVCT40/BIN/INC/LIB -- I assume that's a change between those ARM compiler versions.
• There is no PK directory tools\ads_v4_1 in the PK directories to match the RVDS_EXT set here -- however, there's also no tools\ads_v4_0 (just tools\ads_v3_1); so I assume it's not needed?
• Note I created a setenv_RVDS4.0.cmd also, but that's trivial (and you can only add one file per post).

Howie

I am trying to use a Netduino Plus board to replace the legacy controller for an industrial machine that uses a 9-bit serial protocol (the remote process controllers only read bytes with the 9th bit set until they see a packet addressed to them). Life is good if I specify 8 data bits, but if I set 9 it throws an unhandled System.ArgumentException at Microsoft.SPOT.Hardware.SerialPort.dll!System.IO.Port.InternalOpen() (call made at Line 156 of the 4.1 source file SerialPort.cs) Here's my code: mSerial = new SerialPort(SerialPorts.COM1, 375000, Parity.Even, 9); mSerial.DataReceived += new SerialDataReceivedEventHandler(mSerial_DataReceived); mSerial.Open(); I assume the DLL is complaining about a parameter it can't fully handle (9th bit needs a special register bit write; obviously not included in the data byte). Not sure if this is a SecretLabs or MS issue. Would changing to 4.2 firmware fix it? (I tried, but I gave up fighting the driver incompatibility of the Atmel tiny booter.) How do I fix this myself? First time trying managed code for low-level; reminds me of the old days when Windows worked great at the GUI high level before a low-level crash ;-) Howie Goodell

...

I will test a modified Initialize and also add functions to set the 9th bit for certain characters, etc., and contribute them back for anybody else who has similar requirements.

BTW, have you created a solution for loading unmanaged code at runtime as you suggested in this 2010-2011-2012 thread? http://forums.netdui...28-native-code/

Thanks much!
Howie

Hello again,

I'm trying to add just a half-dozen functions to do specific things with serial and other hardware; think I can get adequate speed just using C# for the overall framework. Chris, the Adeneo interop post you linked to last year seems to get me tantalizingly close:
http://adeneo-embedd...-framework.html
However, I'm still stuck in a few places.

1. Question: he suggested creating the Visual Studio project in
"PortingKit\Solutions\[Your Solution]\ManagedCode\",
-- so I just created that directory: in my case C:\MicroFrameworkPK_v4_1\Solutions\Serial9\
However, as I worked through his procedure, I found I needed to manually copy over various top-level files like dotnetmf.proj and folders like TinyCLR from another solution. I assumed the Template solution was correct, but he didn't say where they should come from. Do you think he assumes we initially created the solution with the MS SolutionManager he called "flimsy"??

2. A detail about his procedure: he says to edit the .featureproj file to point to the .pe (Portable Executable) file from the Library project -- but in VS2010 at least, there are TWO versions of .pe and other binary files, in two directories named:
bin/Debug/le and
bin/Debug/be .
Googling wasn't too helpful -- I mostly found "le" on French pages ;-) It turns out the choice matters: be is Big-Endian and le is Little-Endian. The ARM defaults to Little-Endian, (though initialization could change it, I'm sure yours doesn't). If you are using a Big-Endian processor, you also need to use Template_be as your model instead of Template, apparently.

3. A request for Chris: would it be possible to post a link to the 4.1 firmware sources again? I only see 4.2 on your Downloads page. Because I had trouble with the USB drivers for the boot re-flash that 4.2 firmware requires, I'd rather not mess with all that just to make these small changes. However, I can't create an image for 4.1 without them, unless perhaps I link to the downloaded object as someone suggested -- but I'd rather have all source.

4. Finally, just to clarify: although MFDeploy says it can do incremental downloads, I haven't found any procedure for that. I'd love to just deploy my small changes linked against the existing image, with or without GUI niceties. However, at this point I plan to link and compile the whole thing; then re-flash following this procedure in the wiki:
http://wiki.netduino...ep-by-step.ashx
If there is an incremental deployment procedure, I'll gladly add a wiki page explaining it, once someone explains it to me ;-)

Cheers!
Howie