Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Netduino Plus 2 Firmware v4.2.1 (Update 2)


  • Please log in to reply
57 replies to this topic

#1 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 December 2012 - 09:28 AM

Version: 4.2.1 Update 2 (version 4.2.1.2)

This firmware requires use of the .NET Micro Framework v4.2 SDK (QFE2) and Netduino 4.2.1.0 SDK.

With this firmware, you will have the following resources available for your code:
384KB Flash
100KB+ RAM

This firmware includes the following updates:
1. Static IP now works (in addition to DHCP default)
2. MAC Addresses are now loaded by TinyCLR
3. Additional I2C bug fix--pins now forced into proper configuration

To find the current version of your Netduino firmware:
1. Go to the Start Menu > Programs > Microsoft .NET Micro Framework 4.2 > Tools
2. Run MFDeploy.exe. Be careful to run MFDeploy.exe and not MFDeploy.exe.config (as file extensions are hidden by default)
3. Plug your Netduino into your PC using a Micro USB cable.
4. In the Device section at top, select USB instead of Serial. Your Netduino should appear in the drop-down; if not, select it.
5. Select the Target menu, Device Capabilities option.
6. In the output box, find the "SolutionReleaseInfo.solutionVersion" value. This is your firmware version.

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 bootloader mode.
3. Erase the firmware on your Netduino using the STDFU Tester application
> a. Select the "Protocol" tab
> b. Press the "Create from Map" button
> c. Select the "Erase" radio button option
> d. Press the "Go" button
> e. Wait for erase process to complete
4. Flash the attached .DFU file using the ST DfuSe Demonstrator application (included with STDFU Tester)
> a. Locate the "Upgrade or Verify Action" pane (bottom-right pane)
> b. Press "Choose..." and select the attached DFU file
> c. Check the "Verify after download" option
> d. Press "Upgrade". It will take a few minutes to update your Netduino.
> e. Detach and reattach your Netduino (power cycle) or press "Leave DFU mode"

After flashing, to set your network settings using MFDeploy:
1. Select the Target > Configuration > Networking menu. Re-enter your IP address settings and MAC address.

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

Chris

Attached Files



#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 December 2012 - 09:53 AM

A few quick notes (known issues, temporary workarounds, etc.):

I2C bug fix
The I2C pins weren't getting re-configured every time in the previous firmware. This has been remedied. Please let us know if it works (or doesn't work) for you.

If you are using shields with I2C on A4/A5, add jumper wires between A4/A5 and SDA/SCL and your code should work great. This is required for the revised Arduino R3 layout.

That said...we will also be adding a software I2C feature to Netduino Plus 2 in late December. This will enable A4/A5 to be used with I2C devices mirroring the SDA/SCL pins. You'll also be able to use A4/A5 as a second I2C bus, in addition to the dedicated SDA/SCL pins.

Our goal is to maintain as close to 100% backwards-compatibility as possible, even while getting all the new features and hardware upgrades--and even with the new MCU architecture.

Static IP and MAC Address settings
Network settings were not getting loaded properly by the ENC28J60 driver. This should be working now.

AnalogInput and PWM classes
The legacy SecretLabs.NETMF.Hardware.AnalogInput and SecretLabs.NETMF.Hardware.PWM classes have been replaced by the new "standardized" Microsoft.SPOT.Hardware.AnalogInput and Microsoft.SPOT.Hardware.PWM classes.

We have heard from many users who want to use their existing code, using the legacy classes, with the new hardware. It's requiring a bit of plumbing work, but we'll have an update soon which enables you to use the legacy classes with the new hardware.

In the meantime, you can use the new standardized classes with the AnalogChannels.### and PWMChannels.### enumerations. Please note that "s" at the end of these names.

Netduino SDK 4.2.1.x December update
Normally with .NET MF, anytime you change boards you need to remove the current Hardware Provider and replace it with the target board's Hardware Provider DLL.

With Netduino Plus 2, we've designed a new mechanism for the Netduino hardware provider (SecretLabs.NETMF.Hardware.Netduino.dll). This mechanism allows you to deploy Netduino projects to Netduino Plus 2 without changing the Hardware Provider DLL in your project references.

We will be taking this a step further in the December SDK update, enabling Netduino Plus 1 projects to be upgraded to Netduino Plus 2 without changing out the Hardware Provider DLL.

In the meantime, if you are upgrading your Netduino Plus 1 projects to Netduino Plus 2:
  • Remove the SecretLabs.NETMF.Hardware.NetduinoPlus.dll reference from your project.
  • Add the SecretLabs.NETMF.Hardware.Netduino.dll reference to your project
  • Change the deployment target in Project Properties > .NET Micro Framework.
Final note
We'll have more updates soon. As with all Secret Labs products, we want to make sure everyone is having a great experience with their new hardware.

Thank you to all of you who are picking up Netduino Plus 2 and pushing all the edge cases,

Chris

#3 JerseyTechGuy

JerseyTechGuy

    Advanced Member

  • Members
  • PipPipPip
  • 870 posts

Posted 03 December 2012 - 11:23 AM

Chris,

The update went smooth. The board is running 4.2.1.1.

I redeployed my quick I2C check app with the ADXL345 sensor and I am getting the same results. The debug pointer is off and showing ChargerModel not I2CDevice.

As I step through the code the sensor still isn't returning any bytes when written to. It's basically doing the same thing as before.

UPDATE: 7:06am 12/3/2012

I double checked the firmware version using MFDeploy and all looked OK. I was going to reflash the board again just to be sure but did not. I headed back to my test project and redeployed it 2-3 times with the same results. So I decided to build a test rig with the ADXL345, the DS1307 RTC and the LCD Backpack.

Once I finished the hardware I made code changes to test all 3 devices and redeployed. Suddenly it all worked. No references were changed and no code around I2C. There is more initialization code running now to init the LCD and RTC so perhaps the extra steps have introduced a delay of some sort that allowed enough time for I2C to initialize.

Bottom line... it seems to be working now. I'll do some more testing with the other I2C devices I have here.

#4 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 03 December 2012 - 12:29 PM

Bottom line... it seems to be working now. I'll do some more testing with the other I2C devices I have here.

Ok good to know. Thanks for the update!
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#5 JerseyTechGuy

JerseyTechGuy

    Advanced Member

  • Members
  • PipPipPip
  • 870 posts

Posted 03 December 2012 - 04:51 PM

I've continued to work on some projects throughout the day and have experienced some intermittent I2C issues. I'll do some more testing but here are the scenarios that seem to be occurring... 1) If I reboot the board from software using "PowerState.RebootDevice(<true> or <false>, 100);" to do either a hard reboot or soft reboot it seems I2C doesn't always come back up properly. It seems to be failing on I2C Device creation. If I then remove the power or hit the reset button, it will come up fine most of the time (had to reboot it more than once a time or two). 2) In some cases when I power up the board it seems to take a long time (maybe 20 seconds) before the I2C device is created and continues to execute the code. For example, if I have an I2C LCD Backpack running, when I boot the ND+ board the display shows instantly but on the ND+2 it occasionally will remain blank for up to 20 seconds then display the test and set the background color of the RGB LCD. It sets the color after the text is sent. I can see it takes about 20 seconds before the LCD Color changes which means it is hanging the code. I'll post back if I discover anything more.

#6 Günter

Günter

    New Member

  • Members
  • Pip
  • 1 posts

Posted 03 December 2012 - 05:32 PM

Hello, i have my NP2 2 days :-) i will try to flash the new firmware. My update-problem is solved now !!! Günter

#7 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 December 2012 - 06:06 PM

Hi Dave,

I've continued to work on some projects throughout the day and have experienced some intermittent I2C issues. I'll do some more testing but here are the scenarios that seem to be occurring...

I'm very happy that I2C is working for you now, at least most of the time. I really appreciate your patience while we sort through the issue and get it to work 100% of the time for you :)

Regarding reboot...we've tested that in both hard mode (same as asserting GND on the reset header) and soft mode with our Gravitech shield a few hundred times and it always comes back. So this might be something related to circuitry or logic in one of the devices you're using. I2C is the most complicated peripheral feature due to all the moving parts (strength of pull-up(s), # of devices, length of wires, alternate function settings, i2c peripheral enable settings, start-bit-sent interrupts, open drain, rise and fall time, voltage of pull-ups, etc.) But if we can narrow this down to a simple repro case, we can get the hardware and repro here (so we can get everything working well).

Can we isolate your I2C bus to one device to start with? And then create a 10-20 line repro that recreates the issue? We can then make sure all the devices are working...and then put them all on the bus together (while making sure we're using pull-up resistors with an I2C-calculated value).

Thanks Dave!

Chris

#8 baxter

baxter

    Advanced Member

  • Members
  • PipPipPip
  • 415 posts

Posted 03 December 2012 - 07:40 PM

Hi Chris, I just updated my Plus 2 and everything is working perfectly with networking. Thanks for your hard work on this. The old Netduino Plus now seems sluggish compared with the new Plus 2. Baxter

#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 December 2012 - 09:06 PM

I just updated my Plus 2 and everything is working perfectly with networking. Thanks for your hard work on this. The old Netduino Plus now seems sluggish compared with the new Plus 2.

Awesome. Thanks for the update, baxter!

The new board is quite fast. :)

Chris

#10 Lunddahl

Lunddahl

    Advanced Member

  • Members
  • PipPipPip
  • 152 posts
  • LocationEurope, Denmark

Posted 04 December 2012 - 01:06 AM

2. MAC Addresses are now loaded by TinyCLR


Do we need to use MFDeploy to set the MAC address manually to whatever is printed on the sticker on the bottom of the board, because it seems that my NP2's are still using 00:04:a3:00:00:00 ?

In the future when i erase the NP2 with STDFU Tester, do i also erase the MAC address ?

- Ulrik Lunddahl

#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 04 December 2012 - 01:13 AM

Hi Ulrik,

Do we need to use MFDeploy to set the MAC address manually to whatever is printed on the sticker on the bottom of the board, because it seems that my NP2's are still using 00:04:a3:00:00:00 ?

In the future when i erase the NP2 with STDFU Tester, do i also erase the MAC address ?

Yes, you'll need to set the MAC address and IP address after erasing and reflashing the board.

The STM32 chips have OTP in them so we're thinking of saving MAC addresses there in the future. That would make it easy to automatically pick up on the MAC settings after reflash--although IP settings would need to be preserved otherwise.

Chris

#12 Lunddahl

Lunddahl

    Advanced Member

  • Members
  • PipPipPip
  • 152 posts
  • LocationEurope, Denmark

Posted 04 December 2012 - 01:35 AM

Yes, you'll need to set the MAC address and IP address after erasing and reflashing the board.


And when i do it works perfectly, i'm only setting the MAC, as i use DHCP.

The STM32 chips have OTP in them so we're thinking of saving MAC addresses there in the future. That would make it easy to automatically pick up on the MAC settings after reflash--although IP settings would need to be preserved otherwise.


That will be welcomed, especially because the MAC address is printed on the board.

- Ulrik

#13 mobilegamer999

mobilegamer999

    Member

  • Members
  • PipPip
  • 12 posts

Posted 04 December 2012 - 02:50 AM

My netduino still appears to be having problems with it's I2C connection. I have upgraded to 4.2.1.2 but have had no luck with actual data transmission. Throwing a scope on the SDA/SCL lines they ARE changing state unlike they were doing before but no data is actually being registered as sent. On top of that when I do

new I2CDevice(new I2CDevice.Configuration(0x53, 100));
That crashes with a "An unhandled exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.dll" error.
However, when I use the I2CBus class (attached) there is no crash and I can see the pin states changing appropriately but the system doesnt register and data actually being sent. These are the transactions that I am attempting currently.

byte[] data = new byte[6];
ReadAccel = new I2CDevice.I2CTransaction[]
{
     I2CDevice.CreateWriteTransaction(new byte[]{0x30}),
     I2CDevice.CreateReadTransaction(data)
};

Attached Files



#14 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 04 December 2012 - 03:01 AM

And when i do it works perfectly, i'm only setting the MAC, as i use DHCP.
That [[OTP setting of MAC]] will be welcomed, especially because the MAC address is printed on the board.
- Ulrik


In truth, personally, I'd prefer to not be constrained to OTP MAC address. Or more precisely, I'd prefer to have the ability to override the OTP setting, something logically like this pseudocode:

effectiveMAC = ( 0 == configMAC ) ? otpMAC : configMAC

-dave

#15 JerseyTechGuy

JerseyTechGuy

    Advanced Member

  • Members
  • PipPipPip
  • 870 posts

Posted 04 December 2012 - 03:38 AM

My netduino still appears to be having problems with it's I2C connection. I have upgraded to 4.2.1.2 but have had no luck with actual data transmission. Throwing a scope on the SDA/SCL lines they ARE changing state unlike they were doing before but no data is actually being registered as sent. On top of that when I do

new I2CDevice(new I2CDevice.Configuration(0x53, 100));
That crashes with a "An unhandled exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.dll" error.
However, when I use the I2CBus class (attached) there is no crash and I can see the pin states changing appropriately but the system doesnt register and data actually being sent. These are the transactions that I am attempting currently.

byte[] data = new byte[6];
ReadAccel = new I2CDevice.I2CTransaction[]
{
 	I2CDevice.CreateWriteTransaction(new byte[]{0x30}),
 	I2CDevice.CreateReadTransaction(data)
};


I've done quite a bit of testing throughout the day with several different sensors, LCDs, RTCs, etc and experienced no major issues like you are describing. Can you provide a little more info so we can help you out? Like what I2C device are you trying to communicate with? How is it wired? Are you referencing the correct DLLs (Netduino DLL not Netduino Plus DLL)?

#16 mobilegamer999

mobilegamer999

    Member

  • Members
  • PipPip
  • 12 posts

Posted 04 December 2012 - 04:16 AM

I've done quite a bit of testing throughout the day with several different sensors, LCDs, RTCs, etc and experienced no major issues like you are describing. Can you provide a little more info so we can help you out? Like what I2C device are you trying to communicate with? How is it wired? Are you referencing the correct DLLs (Netduino DLL not Netduino Plus DLL)?


I have a N+2 Wired into an ADXL345 with appropriate pull-up resistors. And how can I check to make sure I am reference the appropriate DLL's?

#17 DaveRVW

DaveRVW

    Advanced Member

  • Members
  • PipPipPip
  • 37 posts

Posted 04 December 2012 - 06:43 AM

Hint: when troubleshooting i2c it can be useful to put the transactional code into a loop, with a delay between iterations, so you can tweak your circuit to see if you get different results And update 2 works for me talking to Microchip 24FC1025 jumpered directly to SCL/SDA. Both running in debugger, and running standalone (USB removed, supplying external 5V power) outputing results to SerialPort.

#18 JerseyTechGuy

JerseyTechGuy

    Advanced Member

  • Members
  • PipPipPip
  • 870 posts

Posted 04 December 2012 - 11:29 AM

I have a N+2 Wired into an ADXL345 with appropriate pull-up resistors. And how can I check to make sure I am reference the appropriate DLL's?


In Visual Studio, expand the references branch. For the ND+2 you should be referring to SecretLabs.NETMF.Hardware.Netduino instead of SecretLabs.NETMF.Hardware.NetduinoPlus. If you are seeing SecretLabs.NETMF.Hardware.NetduinoPlus, just click it and delete it, then choose "Add Reference" and add the SecretLabs.NETMF.Hardware.Netduino.dll version 4.2.1.0.

#19 mobilegamer999

mobilegamer999

    Member

  • Members
  • PipPip
  • 12 posts

Posted 04 December 2012 - 05:36 PM

In Visual Studio, expand the references branch. For the ND+2 you should be referring to SecretLabs.NETMF.Hardware.Netduino instead of SecretLabs.NETMF.Hardware.NetduinoPlus. If you are seeing SecretLabs.NETMF.Hardware.NetduinoPlus, just click it and delete it, then choose "Add Reference" and add the SecretLabs.NETMF.Hardware.Netduino.dll version 4.2.1.0.


It is only referencing the SecretLabs.NETMF.Hardware.Netduino dll.

EDIT:
For further clarification,
I tried the NetduinoPlus dll just to see what would happen and it does not crash and the pin states DO change, but there is no data that is being read in/out;
And with the Netduino dll (not plus) it crashes when I attempt to instantiate a I2CDevice instance.

#20 Lunddahl

Lunddahl

    Advanced Member

  • Members
  • PipPipPip
  • 152 posts
  • LocationEurope, Denmark

Posted 04 December 2012 - 10:51 PM

In truth, personally, I'd prefer to not be constrained to OTP MAC address. Or more precisely, I'd prefer to have the ability to override the OTP setting, something logically like this pseudocode:

effectiveMAC = ( 0 == configMAC ) ? otpMAC : configMAC


My issue is that reflashing requires you to manually set the MAC address, differently for every board, that makes in field firmware upgrades hard to handle.

But lets say that the MAC on the sticker is stored in OTP, and used only if the MAC address in the firmware flash is either the default one or is invalid, like 00:00:00:00:00:00

If i understand it correctly the network is initialized before the CLR takes over, so setting it there is not optimal, but should also work in some scenarios where you want to switch MAC address on the fly in you application.

What i just explained is what you meant with you ternary pseudocode, right ?

- Ulrik




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.