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

TristatePort bug on Netduino Plus 2


  • Please log in to reply
6 replies to this topic

#1 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 29 December 2012 - 08:27 AM

I am not sure if anyone already noticed this bug, and I would love that someone tries to reproduce this behavior.

For me it's pretty easy to repro, using a snippet like this one:

 

 
            var sda = new TristatePort(Pins.GPIO_PIN_D11, false, false, Port.ResistorMode.Disabled);            sda.Active = true;            sda.Active = false;            sda.Active = false;  //InvalidOperationException

 

In brief, it seems that it is raised an exception when you set the same value already present in the "Active" property.
I did not find relationship to the I/O used, nor the boolean value assigned: just the same.

 

Of course, the workaround is pretty easy, but until I did not understand the cause I experienced something like:

- the debugger is not able to give me info about the "sda" instance, but any other variable/instance does. Go to "Watch" pane and type the "sda" instance, it yields the following result:

 

Unable to evaluate the expression. An error occurred that usually indicates a corrupt installation (code 0x80004002). If the problem persists, repair your Visual Studio installation via 'Add or Remove Programs' in Control Panel.
 
- Under certain circumstances such the above (once only, thus hard to repro) the N+2 frozen and there was no way to rescue it by pushing the reset button. During the deployment, which seemed broken, I unplugged the USB cable and my PC blued the screen (kernel exception), then restarted completely the machine (without let me choose).
 
Let me know.
Cheers

Biggest fault of Netduino? It runs by electricity.

#2 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 31 December 2012 - 12:06 PM

I have checked the source code and it indeed throws the InvalidOperationException when the Active property is set to the same value, resp. to be more precise when the port direction (input/output) is already set. I am not sure why the exception is thrown, there is nothing else done in that code path, and there is no limitation described in the documentation. You might want to report this issue on .NET MF CodePlex.



#3 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 31 December 2012 - 05:38 PM

Hmm...I also checked the MF sources, but it's clear that I didn't look the right place (that's normal, though).

So, you say that this bug belongs to the MF and not to Netduino or STM porting?

Honestly I didn't on the old Netduino Plus, but I wonder how none realized a so easy-to-reproduce bug along the life of these products...

I will add this issue, but -please- tell me whether you are sure about the main MF (thus any derivation).

Everybody have a good year eve!


Biggest fault of Netduino? It runs by electricity.

#4 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 31 December 2012 - 07:59 PM

It's implemented in CLRLibrariesSPOT_Hardwarespot_hardware_native_Microsoft_SPOT_Hardware_TristatePort.cpp, line 48:
 

HRESULT Library_spot_hardware_native_Microsoft_SPOT_Hardware_TristatePort::set_Active___VOID__BOOLEAN( CLR_RT_StackFrame& stack ){    // ...    if( ( activate && ((flags & GPIO_PortParams::c_Output) == 0)) ||        (!activate &&  (flags & GPIO_PortParams::c_Output)     )    )    {        TINYCLR_CHECK_HRESULT(Library_spot_hardware_native_Microsoft_SPOT_Hardware_Port::ChangeState( pThis, port, activate ));    }    else    {        TINYCLR_SET_AND_LEAVE(CLR_E_INVALID_OPERATION); // <--- This causes InvalidOperationException to be thrown in the managed code    }        TINYCLR_NOCLEANUP();}

And yes, it is not platform/device/board-specific, this is .NET MF core assembly.



#5 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 01 January 2013 - 04:51 AM

I've never understood why this is the behavior of the NETMF TristatePort.Active property, but it is how the class was designed to operate.

 

This would be great to bring up as an issue at netmf.codeplex.com.  If there are no adverse effects from removing this exception, it would lower the learning curve on using TristatePort.  It would also remove the need for a lot of "if (tristatePort.Active)" code.

 

Chris



#6 Sukasa

Sukasa

    Advanced Member

  • Members
  • PipPipPip
  • 32 posts
  • LocationNanaimo, BC

Posted 30 March 2015 - 09:14 PM

It's a bit of a bump, but I made an issue + pull request for this on the .NETMF github and any support would be appreciated!

 

E: Link



#7 Sukasa

Sukasa

    Advanced Member

  • Members
  • PipPipPip
  • 32 posts
  • LocationNanaimo, BC

Posted 13 April 2015 - 11:10 PM

Quick update to this - once .NETMF 4.4 is released, this will not be an issue.  The pull request to remove the managed code crash just got merged, and setting this property to its current value will simply do nothing, without throwing an exception.






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.