7 replies to this topic

[Robert L.]

There seems to be something different about the way pin A2 powers up. Previously, and I am not sure how far I need to go back, the pin in question: GPIO_PIN_A2 as in

private static SecretLabs.NETMF.Hardware.AnalogInput POR = new SecretLabs.NETMF.Hardware.AnalogInput(Pins.GPIO_PIN_A2);

used to power up in a high impedance state. Now it seems to power up in a low impedance state, outputting a logic LOW, and then later get switched to a high impediance state, I assume when my code declaring the pin gets executed. I declare this pin in a class that gets created several milliseconds after a reset, perhaps there is a better way to declare it so it's initial state is as an input pin rather than an output pin. Perhaps I am mistaken and the pin always worked this way.

Any pointers would be appreciated.

Robert

[Robert L.]

OK, so lots of views, but no replies. Perhaps no one knows the answer, or no one figures this is an important issue. Let me explain a bit more - why this is important to me. Generally GPIO pins on most processors power up in the "input" mode, since that is less likely to cause external circuits trouble. In my case, the pin in question is connected to a simple RC charging circuit. The idea is to try and tell the difference between a power-on-reset and a watchdog reset. With a power-on-reset, the 3.3 volts will be absent for a time, so when the processor starts up it will read a low voltage (for a few seconds) from the RC circuit. On the other hand, if the processor was reset (rebooted) by some means other than a power-on-reset, then the RC circuit will have a high voltage. On OS versions before 4.2.0, this circuit worked as desired, but with the latest version, the output pin is placed in a low impedance mode for a short time, I assume until it encounters my code setting it for use as input to the ADC. This low impedance causes the RC circuit to discharge. The effect is that all resets look like power-on-resets now. Making it no longer possible to distinguish between POR and some other kind of reset. So the question is: is there a way to stop the OS from placing this pin in a LOW state during initialization? It used to work and now doesn't, even though my code is unchanged. Consider this an "extra credit" question on the final exam.

[Ellen]

I had to load the separate secretlabs .dll in the reference to work with the A_ports in version 4.2

[Robert L.]

I had to load the separate secretlabs .dll in the reference to work with the A_ports in version 4.2

Ellen, thank you for your reply. I have the following loaded:

SecretLabs.NETMF.Hardware.AnalogInput 4.2.0.1 v4.0.30319
SecretLabs.NETMF.Hardware.NetduinoPlus 4.2.0.1 v4.0.30319

Are you using something different from these?

[Robert L.]

Generally GPIO pins on most processors power up in the "input" mode.

So the question is: is there a way to stop the OS from placing this pin in a LOW state during initialization? It used to work and now doesn't, even though my code is unchanged. Consider this an "extra credit" question on the final exam.

Still trying out things here on my own, since there has been no word from Secret Labs on this issue. I find that if the pin is defined as an input, the low impedance situation does not occur:

static InputPort  PORpin    = new InputPort(Pins.GPIO_PIN_A2, false, Port.ResistorMode.Disabled);

Does not result in a low impedance following a reset. So this seems to point to an issue with the class:

SecretLabs.NETMF.Hardware.AnalogInput

Has something changed in this class with the last release that effects the imdedance following a reset or for a short time after the pin is declared?

[Chris Walker]

Hi Robert, If you erase your app, unplug your Netduino, and then plug it back in...what state do you see the pin in? The pins should all boot in input mode, pull-ups enabled. If they're not doing so, we'll need to dig into the source and fix that. Chris

[Robert L.]

The pins should all boot in input mode, pull-ups enabled. If they're not doing so, we'll need to dig into the source and fix that.
Chris

Attached is a scope image of a reset which occurred due to something other than a power cycle. The YELLOW colored trace is the voltage on pin A2. The BLUE trace is an output pin that I am using to help debug. Pin A2 is connected to an RC circuit, IE capacitor to ground, resistor to 3.3V. The reset point is when the A2 pin drops sharply from around 2 volts to near zero. A2 then stays held to zero until processing starts, IE when the BLUE trace first goes to a logic one.

Pulling A2 to zero this way occurs when the pin is defined as an analog input:

SecretLabs.NETMF.Hardware.AnalogInput PORpin = new SecretLabs.NETMF.Hardware.AnalogInput(Pins.GPIO_PIN_A2);

But not when the pin is defined as a input port:

InputPort  PORpin    = new InputPort(Pins.GPIO_PIN_A2, false, Port.ResistorMode.Disabled);

My conclusion is that something changed in the class: SecretLabs.NETMF.Hardware.AnalogInput in a recent release. Pin A2 did not get pulled to zero this way before.

I do now have a "workaround" if this cannot be changed back in a timely manner. I determined the voltage thresholds on pin A2 when used as an InputPort. For a rising signal (at least on the board I measured) it is 1.50 volts, for a falling signal it is 1.10 volts. These thresholds and my circuit are such that I can properly detect a power-on-reset vs. "some other reset not caused by a power cycle" using the pin as an InputPort and just reading logic levels. However I do feel that pulling the analog pin to ground during program initializations is wrong and should be fixed.

Attached Files

•  TEK00000.PNG   10.61KB   16 downloads

[Chris Walker]

Hi Robert, The SecretLabs AnalogInput class is now a wrapper around the new "standardized" NETMF AnalogInput class. So this is probably something which has changed at a lower level in the newest firmware. We will pull this into the lab and sort through it. Thank you very much for your feedback on this one. I recommend using a workaround for now. There are a lot of coordinated firmware updates coming (GoBus 1.5, NETMF 4.3, support for this weekend's announcements, etc.) so I don't want to promise you a date that could risk your schedule. Chris