MSP430F5528, state of port pins in reset

From section 1.2.1 Device Initial Conditions After System Reset of the user's guide:

After a BOR, the initial device conditions are:
 I/O pins are switched to input mode as described in the Digital I/O chapter.

Table 11-2. Digital I/O Registers shows that the initial value of the port Direction, Resistor Enable and Port Select registers are 00h which means the initial state of the ports are inputs with no pullup/pulldown.

There are three levels of "reset", a BOR, POR and PUC.

The Port x Direction Register (PxDIR) and Port x Pullup/Pulldown Resistor Enable Registers (PxREN) bits are documented as rw-0 which means they are a zero after a PUC. The MSP430x5xx/MSP430x6xx Family User's Guide SLAU208J doesn't seem to explicitly state which type of reset sets the Port Select register to the initial value but guess the port select registers are reset by a PUC the same as the other Digitial I/O Module ports. i.e. the I/O pins are switched to the input mode by a PUC which occurs if the reset source is a BOR, POR or PUC.

Right, the behavior of the port pins *after* reset is pretty well documented.

I am asking what their state is *during* reset so the power is on but the reset line is being held low. My complete guess is that they are tri-stated.

I did a search on the word "reset" through the whole of SLAU208 and saw no reference to this.

Thanks.

Mike

From my understanding, the three reset conditions BOR, POR and PUC differ in the moment thy happen.
BOR-reset register contents are reset(or set) by the BOR event itself. This means, as soon as power fails or RST is pulled low.
POR initialization happens when the MSP internally initializes (after RST is released or VCC has risen above BOR threshold) and PUC likely is a software initialization done by the MC startup code. But that's just guessing - there are no evidences about what really happens.
The only reference to this question is 1.9:Boot code. But this 3-liner leaves the question how registers are initialized after a PUC, if the boot code only executes after a BOR. So it is misleading at best.

However, PUC initialization does not mean it isn't initialized by BOR or POR too, just that it will be initialized even if there is just a PUC.

Indeed, the datasheet isn't too clear about when what will be initialized.

Experience shows, that port pin registers are switched to high-impedance GPIO inputs the moment RST is pulled low (BOR is active). But it isn't documented anywhere.

There is this erratum for the MSP430F5528:

PORT16 Digital I/O Module

Function: GPIO pins are driven low during device start-up

Description: During device start-up, all of the GPIO pins are expected to be in the floating input state.

Due to this erratum, some of the GPIO pins are driven low for the duration of boot code execution during device start-up, if an external reset event (via the RST pin) interrupted the previous boot code execution. Boot code is always executed after a BOR, and the duration of this boot code execution is approximately 500 μs.

For a given device family, this erratum affects only the GPIO pins that are not available in the smallest package device family member, but that are present on its larger package variants.

If interrupting the boot code with an exernal reset can effect the next boot code execution, that suggests a external reset doesn't  completly clear the device status.

Chester Gillon said:

If interrupting the boot code with an exernal reset can effect the next boot code execution, that suggests a external reset doesn't  completly clear the device status.

The only thing I can imagine is that the boot code, when interrupted, leaves some internal state at a position where it causes the boot code to set the ports to low outputs on next run (independently of their former state!) until it finishes and sets them high again.
If there woud be no hardware reset, the port pins would be in undefined state after every reset until the boot code finishes. Which apparently doesn't happen.

Also, why does it happen only to port pins which are not available in all packages? Why not to all port pins? THis makes me guess that the hardware reset does  only happen for port pins (port registers) which are on the smalles package (probably the first device of the sereis) and the additional ports on teh 'bigger' deices are controlled by the boot code only.
Still, then they would be undefined or at least unchanged after every reset.

One thing that's also possible: after a real power-up, the pins are cinfigured inputs on hardware level (internal power-up reset), while on a RST-caused BOR, the boot code performs the resetting of the registers. So if you apply an RST, the pins remain in their current state until the boot code switches them back to init state.
Based on this erratum, that's the most likely interpretation of what's happening.

However, I just tested again on my 1611 board I have on the desk, and when I pull down RST, the LEDs go immediately off, so it must be hardware.
Brings me back to the idea that the 'additional' ports on those affected MSPs are not connected to the reset hardware for some reason. And the boot code has a bug.

#include <msp430.h>

/*
 * main.c
 */
void main(void) {
  WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT

  // Turn on up LED1 and LED2
  PJOUT = BIT1 | BIT0;
  PJDIR = BIT1 | BIT0;

  int i;
  if (PM5CTL0 & LOCKLPM5)
  {
    // Need to clear LOCKLPM5 to allow software control of the outputs
    PM5CTL0 &= ~LOCKLPM5;

    // Toggle LED2 to indicate LOCKLPM5 was set on start up
    for (i = 0; i < 10; i++)
    {
      __delay_cycles (100000);
      PJOUT ^= BIT1;
      __delay_cycles (100000);
      PJOUT ^= BIT1;
    }
  }
  else
  {
    // Toggle LED1 to indicate LOCKLPM5 was clear on start up
    for (i = 0; i < 10; i++)
    {
      __delay_cycles (100000);
      PJOUT ^= BIT0;
      __delay_cycles (100000);
      PJOUT ^= BIT0;
    }
  }

  // Enter LPM4.5 with LED1 and LED2 on
  PMMCTL0_H = PMMPW_H;
  PMMCTL0_L = PMMREGOFF;
  __bis_SR_register(LPM4_bits);
}

Jens-Michael Gross said:

However, I just tested again on my 1611 board I have on the desk, and when I pull down RST, the LEDs go immediately off, so it must be hardware.

This forum editor is strange! It ommited the following from my previous post:

With a device which supports LPMx.5 have found that the "state" of the processor at the point RST is pulled down can affect the behaviour. With the attached program running on a MSP-EXP430FR5739:

1) If RST is pulled down while the processor is running the LEDs go immediately off. When RST is released the program indicates LOCKLPM5 was clear at startup.

2) If RST is pulled down after the processor has entered LPMx.5 the LEDs remain on while RST is pulled down. When RST is released the program indicates LOCKLPM5 was  set at startup.

Chester Gillon said:

If RST is pulled down after the processor has entered LPMx.5 the LEDs remain on while RST is pulled down.

The reason is that this way, the processor can completely shut down, including ram retention and processor registers. While the port pins continue to drive or sense like configured.