Stupid little problem is killing my program...

20 May 2012

My MBED run a program that controls external circuit boards via PWM & DigitalOut Signals... The problem I'm having is that two of the Digital Out pins (19 & 20) trigger an action on a slave board for a brief moment when the MBED starts up. Without getting into detail this triggers a fault in the overall system.

What I want is be able to declare the Digital Out pins and ensure they do not power up at all unless the program asks them to... In other words, set them low right away.

Here's what is going on...

I declare the pins in the header...

DigitalOut dUS(p19); DigitalOut dDS(p20);

.... do other declarations .....

int main(){

... Very first thing I set them to zero when the program starts

dUS = 0; dDS = 0;

........

The problem is that from the time I declare the pins to the time I set them to zero, They produce a slight power output. But it's enough to trigger the slave board and cause the fault...

Any Ideas?

Thank You

Tim

-

20 May 2012

The safest way is to invert the logic that drives your hardware. Currently it activates on a logic 1. That is also the default level on the mbed during and after reset until you change it to 0. This causes a brief glitch on the outputpin. Invert the driver logic to activate on a 0 and remain idle on a 1. An alternative would be to use a capacitor on the pin. You then need longer periods of 0 and 1 before the C is charged or discharged and the hardware activates. Obviously that slows down normal response time also.. Note that for safety critical applications you need more elaborate solutions like AC coupled square waves outputs or special unlock sequences rather than steady state outputpins.

20 May 2012

As a thought, you could try:

#include "mbed.h"

DigitalInOut dUS(p19); 
DigitalInOut dDS(p20);

int main(){
    dUS = 0;
    dDS = 0;

    dUS.output();
    dDS.output();
}

i.e. set the state of the in before switching it to be an output. I don't have the facilities right now to check this does give that behaviour, but thought it might be worth a mention incase it works.

Simon

20 May 2012

Hi Timothy, Simon,

The DigitalInOut approach, might speed up getting the correct level on your external pin, but it doesnt really solve the problem. What if a user presses the resetbutton for an extended time: the software wont even start running and the external pins stay at their reset level, which is usually input mode with small pull up. This could cause the error condition in your external hardware. I think you need a solution that is intrinsically safe and does not depend on software.

Wim

20 May 2012

Yep, agreed. My note will only avoid driving the pin at the wrong value. To get the correct behaviour when the MCU is in reset/pin is an input, you really do need the right circuit :)

20 May 2012

Hello Timothy

I've been having the same issue. If you look in the datasheet, I think all the pins will start as input with pull-up. This might ruin it for your hardware. My solution to this problem was driving the pins is used low with a MOSFET, driven from a external voltage source. The gates of the MOSFETs was connected to a digital output on the LPC1768, which was set low, when I needed the other pins to have their function. This was a ugly solution, but it worked.

Lerche

20 May 2012

Thank You all for your responses. The insight you have expressed here helps. Although the answer is not what I wanted to hear (need to redesign the hardware on the slave board) At least I feel confident I could not have fixed this via code. I hate when I waste boards :( But it looks like I need to do a redesign for this issue.

Thanks again.

Tim

EDIT: Simon, I did try your suggestion but the result was the same. Not going to be that simple I guess LOL. Thanks.