Connect GPIO to ground internally?

The PTH08080W requires a very low maximal voltage on Inhibit 0.5V, did you measure the voltage on your MSP port pin?

Thank you for the fast response!

GPIO - GND in the launchpad: 0v

GPIO - GND on a custom board with the PTH08080W: ~1.75v

This suggests the pulldown of the MSP is not enough to overrule the pullup of the PTH, but then why did the resistor of 100k PTH - GND work, while the pulldown resistor should only be 20k - 50k?

Tim Mulder said:

... To do so, I thought to connect a GPIO port (1.5 in my case) to ground, by setting it to input and pulldown. ...

Yes, you can do so by running proper code. For example:

void main (void)
{
  WDTCTL = WDTPW | WDTHOLD;
  P1OUT = 0;
  P1REN = BIT5;
  while (1) { /* do nothing */}
}

Sorry if my initial post was unclear, but this is what I already do, although I use the watchdog as a timer. But it appears not to work, even on another MSP chip.

Tim Mulder said:

...GPIO - GND in the launchpad: 0v

GPIO - GND on a custom board with the PTH08080W: ~1.75v ...

This might also suggest that there is something else wrong with the custom board. Or, the CPU is not running the same code.

The port pin will not be pulled to absolute 0V (datasheet max 0.3V) but what you measure 1.75V is too much. How much is the voltage at Inhibit when it’s floating (disable pull-up/down)?

OCY tries to tell you that OUT must be 0 and Resistor enabled.

I already had the settings OCY advised. When I disable pulldown, the GPIO - GND voltage is ~3.3v, which is almost VCC (3.45v), which seems to point towards insufficient pulldown capabilities of the MSP?
The inhibitory current through pin 5 of the PTH when connected to ground is 1 mA, according to the datasheet. Could it be that there is a current sink clamp on the MSP which prevents proper pulldown in this case?

When it would be 1mA and assume the pull-down resistor is 10K (very minimum) the voltage over the resistor will be 10V. But you misinterpreted the 1mA, it’s when pin 5 and 2 are connected together the module will charge 1mA. The Inhibit pin current when low is 5uA, assume port out is 0.3V and Inhibit 0.5V, diff is 0.2V with a resistor 50K (max) current to Inhibit pin is 4uA, nearly the 5uA so it cannot goes far over the 0.5V but it can be too low to drive Inhibit therefore they advise to use an extra FET. But in your case it’s 1.75V then there must be something wrong with hardware or code.

BTW: It looks like you are toggling the port pin, 3.45V / 2 = near 1.75V!

The data sheet actually says the inhibit input low current is 5 microAmp, not 1 mA. That is why an external 100kOhm pulldown works. MSP430 is capable of doing that with its internal pulldown.

I think you could have made a mistake somewhere else in your code. Good intention is not good enough.

Show us your code, you say you're using  wtd as a timer, to do what? toggling the pull-down state?

Nothing wrong with hard-pull to gnd, (DIR=1 OUT=0) to turn it off, only change DIR=0 to turn it back on.
A 2K series resistor (eg a 2K pull-down) would be nice to protect the mcu pin, in case overvoltage spikes.

The device has a ~50K pull-up (guess) and msp430 pull-down is also ~50K, so you just created a voltage divider.
Though you say it works with a 100K pull-down, are you sure it's not a 10K or 1K?
If you go with 2K resistor, 50K/2K and the voltage divider will be way below 0.5V requirement.

This control pin has an internal pull-up to 3 V (TYP).
Do not place an internal pull-up on this pin. If it is left open-circuit, the module operates when input power is applied.

The Inhibit pin is an open-collector/drain-negative logic input that is referenced to GND.
Applying a low-level ground signal to this input disables the module's output.

When the Inhibit control is active, the input current drawn by the regulator is significantly reduced.

Tony Philipsson said:

Show us your code, you say you're using  wtd as a timer, to do what? toggling the pull-down state?

Nothing wrong with hard-pull to gnd, (DIR=1 OUT=0) to turn it off, only change DIR=0 to turn it back on.
A 2K series resistor (eg a 2K pull-down) would be nice to protect the mcu pin, in case overvoltage spikes.

The device has a ~50K pull-up (guess) and msp430 pull-down is also ~50K, so you just created a voltage divider.
Though you say it works with a 100K pull-down, are you sure it's not a 10K or 1K?
If you go with 2K resistor, 50K/2K and the voltage divider will be way below 0.5V requirement.

This control pin has an internal pull-up to 3 V (TYP).
Do not place an internal pull-up on this pin. If it is left open-circuit, the module operates when input power is applied.

The Inhibit pin is an open-collector/drain-negative logic input that is referenced to GND.
Applying a low-level ground signal to this input disables the module's output.

When the Inhibit control is active, the input current drawn by the regulator is significantly reduced.

Thanks for all the responses so far!

I'm sure it is a 100k, I verified it with a multimeter.

The WTD is used for other, unrelated, purposes. In my project I use Grace to initialize the MSP, but even with a "bare" project, with a main like OCY posted, this works on the launchpad, but does not on the custom board.

It also seems that interrupts are not registered: when I enable a LED in main, it works, but if I do so in an interrupt, it works on the launchpad, but not on the custom board. I even decreased MCLK to 1 mHz (from 16 mHz) and introduced a 10 ms system start-up delay, but no luck so far.

The custom board uses a TI LM317 to power the MCU. The VCC is 3.45v. I suspect this not being the culprit, since code in main is run.

Any ideas?

And what happens when you give it a Reset just with a wire?

It seems my previous post is only partially correct, since only the first (couple of) instructions in main get executed. If I turn a LED on, wait 100000 cycles and order it to turn it off, it stays on. Still no reaction to interrupts, but a reset temporarily turns the LED off, indicating the mcu gets reset.

Don’t you have the possibility to debug?

The reset test was more to force a reset, maybe the power-up reset doesn’t work properly.

Tim Mulder said:

It seems my previous post is only partially correct, since only the first (couple of) instructions in main get executed. If I turn a LED on, wait 100000 cycles and order it to turn it off, it stays on. Still no reaction to interrupts, but a reset temporarily turns the LED off, indicating the mcu gets reset.

If I wait <= 9000 cycles before switching a LED after entering main, it works. For >= 10000 cycles, it does not.

Leo Bosch said:

Don’t you have the possibility to debug?

On the target board, not as of yet. I'll order the MSP-FET today.

TI ships fast, but in the main time you can use your LaunchPad or if your target is a DIL, I made me a short cable on one side DIL-pins (to the LaunchPad) on the other side a DIL-IC-clip, works perfect.

Assume you use 16MHz then the 10,000 is 620uS does this says something to your watchdog or other timers?

It happens me ones (but never more) that the debugger clears all RAM and the program works perfect, but without debugger it won’t run due to one byte was not cleared on start-up.

Tony Philipsson said:

Works on Launchpad but not custom board, is a clear sign that something is not designed right on custom board.
Are you using a 47K pull-up on reset-line etc Are you using crystals for xft1/2 etc?
Or it work on Launchpad as you always run the program from compiler and is therefore in debug mode.
In debug mode fast clks are not shut-down even if your code ask for it.

You can debug with Launchpad, remove any on-board mcu, run short wires of spy-bi-wires from Launchpad to custom boards spy-wire-headers + shared gnd (you did include headers for this I hope)

Thank you all for your fast and very helpful reactions!

It was the missing 47K pull-up. I stupidly thought the pull-up was internal.

So far I'm not using external crystals, but the MSP430G2553 has an internal low frequency oscillator (~12 kHz). Is there a substantial benefit from using an external crystal?

> has an internal low frequency oscillator (~12 kHz). Is there a substantial benefit from using an external crystal?

The internal LF RC  oscillator, is very inaccurate, only useful if you need to sleep for ~10s between checking for something but you don't really care if you sleep for 7sec or if it 14sec.

A crystal attached and the mps430 will be as accurate as your wrist-watch.

Leo Bosch said:

It happens me ones (but never more) that the debugger clears all RAM and the program works perfect, but without debugger it won’t run due to one byte was not cleared on start-up.

Leo, older versions of CCS did not clear uninitialized variables at startup. While that is the definition of ‘uninitialized’, most C compilers init them to 0. And people are assuming that it is the case. The original C specification didn’t cover this, but with later ones it was included in the standard, AFAIK.
Newer CCS versions (since compiler version 4.0, I think) do the init to zero. Which increases the chance that the watchdog will trigger during initialization and also requires additional effort if you really want uninitialized data (that means, data that survives a reset)

 Tim, 5x family and up has an internal pull-up on RST, and on all but 5438 non-A, it is active at start-up (which makes it useless on the 5438 non-A). Previous families don’t have an internal pull-up or don’t have it active at power-on.
In case of a slowly rising supply, an additional capacitor to GND is required too. If not using SBW protocol, 100nF are best. If SBW is used, 2.2nF are max, or pull-up and cap need to be separated from RST (and SBW) by a series resistor of 1k, to reduce the low-pass filter effect on the SBW line.

So this means that for my G2553, the correct solution is indeed to add a 47k pull-up?

I use a LM317 to power the MSP, which, after adding the pull-up resistor, seems to work correctly so far.