• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 80 subscribers
  • Views 1908 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F5335 Pin state when RST held low

Jonathan Valdez
Genius 16510 points
Other Parts Discussed in Thread: MSP430F5335

Hello,

I've have read through the datasheet but see no mention of what happens to the pins during a RST event, but can find information about what happens after. There are some other threads that elude to the possible outcomes, but no solid information.

Background:

Device: MSP430F5335

Pins Used:

H2 - P2.1 (SIMO)

J1 - P2.2 (SOMI)

H4 - P2.3 (CLK)

B1 – P6.6 (CS)

I have a MSP430F5335 acting as master on a SPI bus and I want to temporarily connect another SPI master to USB device connected to my computer so that I can easily communicate with the slave peripherals.

To do this, I pull the RST pin low on the MSP430, which I believe should tri state the pins and leave them floating. However, I am unable to get a response from the slaves.

My guesses at the problem:

Datasheet states that default pin mappings for H2 and J1 are MOSI and MISO. H4 is stated as CLK, and B1 is GPIO. But I do not see anything in the USCI module section that explains what the default state is.

Question:

What are the state of these pins while the RST pin is held low.

  • 0
    Guru 23000 points

    Jonathan,

    Detailed description can be found in the User’s Guide section ‘System Resets, Interrupts, and Operating Modes, System Control Module (SYS)’.

    There you will come to the conclusion that as long RST is Low everything is in his default state. The default state is described in the module’s sections. Which means for the IO pins Input and USCI module disabled.

    Leo.

  • 0 in reply to Leo Bosch
    TI__Genius 16510 points

    Hello Leo, Thanks for pointing me at the user's guide.

    I've done some more reading through there and still have a few follow up questions.

    1) The System Resets section states what happens 'after' a reset. Does this mean that I am to assume that everything resets on the edge transition? There is nothing that states how to treat a POR while it's being held. I will assume that the moment the RST goes low, everything is reset but the PC is not allowed to advance until the RST is pulled high.

    2) I see that the USCI module will become disabled due to the snippet I found below:

    Which does not necessarily explain what the output/input will be set to.

    However, If you look at this snapshot from the datasheet:

    It shows that the default operation of P2SEL will be I/O function. So this should disconnect the USCI module altogether.

    Looking at the default values of the registers, You can come to the following block diagram:

    This leads me to believe that the IO pins should be in a high impedance state during a reset, if during a reset does the same to the registers as after a reset, except that the PC is not allowed to advance.

    Am I correct?

  • 0 in reply to Jonathan Valdez
    Guru 23000 points

    Jonathan,

    I agree it’s not clearly written, therefore I stated ‘you will come to the conclusion’.

    Normally activating a Reset will keep the device into a reset condition. This will be also with the MSP430, otherwise the size of the capacitor wouldn’t have any influence.

    1.2 System Reset and Initialization

    The system reset circuitry is shown in Figure 1-1 and sources a brownout reset (BOR), a power on reset (POR), and a power up clear (PUC). Different events trigger these reset signals and different initial conditions exist depending on which signal was generated.

    A BOR is a device reset. A BOR is only generated by the following events:

    • Powering up the device

    • A low signal on RST/NMI pin when configured in the reset mode

    • A wakeup event from LPMx.5 (LPM3.5 or LPM4.5) modes

    • A software BOR event

    Here you see a BOR is generated by a low RST, which means as long RST is low you have a BOR. In the logic figure “Figure 1-1. BOR/POR/PUC Reset Circuit” I can’t see anything how would change the state of the RST input to BOR.

     

    And here comes the problem where I guess you are pointing to;

    1.2.1 Device Initial Conditions After System Reset

    After a BOR, the initial device conditions are:

    • The RST/NMI pin is configured in the reset mode. See Section 1.7 on configuring the RST/NMI pin.

    • I/O pins are switched to input mode as described in the Digital I/O chapter.

    • Other peripheral modules and registers are initialized as described in their respective chapters in this

    manual.

    • Status register (SR) is reset.

    • The watchdog timer powers up active in watchdog mode.

    • Program counter (PC) is loaded with the boot code address and boot code execution begins at that

    address. See Section 1.9 for more information regarding the boot code. Upon completion of the boot

    code, the PC is loaded with the address contained at the SYSRSTIV reset location (0FFFEh).

    A device Reset is a cycle, not everything can be reset at the same time/moment, therefore a single edge isn’t enough. The capacitor defines the length of this cycle, too short not everything is resets properly, too long you are wasting time. The Data Sheet doesn’t give a precise time value for this cycle but from “Wake-Up From Low-Power Modes and Reset” you can see that the average time needed to begin execution is 2mS.

    So after 2mS and approaching the point ‘After’ the device is in reset and the PC is in hold.

     

    Now when the I/O pins to their defaults the state of the USCI doesn’t matter but it will be also in Reset.

     

    This reset cycle time of 2mS (max 3mS) is relative long, if you have hardwired the RST to low and at the same time enable your other device to use the bus, can give a problem. The I/O reset will be shorter then 2mS but I would add a delay of ~5mS prior to enable the other device to use the bus.

    Leo.

  • 0 in reply to Leo Bosch
    Guru 227245 points

    Leo, I don’t think your explanation is completely correct. And I can understand Jonathan’s concerns.

    There are several states in the timing.

    First there is BOR. It will pull RST down internally.
    BOR, when voltage rises across the threshold, will release RST after some additional internal delay (this may be too short in case of Vcc only slowly rising. This is where the capacitor on RST comes into play.

    Once RST is released, boot code will execute. This boot code will do the configuration of the modules and do the default pin mapping, depending on BOR, POR(RST) or PUC causing it to execute.

    However, some things must be done even before the boot code will execute. Like switching the clock system back to defaults. If e.g. MCLK was too high for the current core voltage, a reset wouldn’t allow the boot code to execute and reset the clock system, if MCLK were still too high. It would simply crash one more.

    So some things have to be done in hardware by the RST signal.
    My guess (and it is only a guess, as the users guide does not confirm it) is that the PxSEL bits are set back to default (this makes it unimportant whether the modules are initialized or not) and the ports are switched to inputs, with pull-ups disabled. And the DCO is reset to default (with MCLK on DCO). And likely, the reset of the status register is also done by the RST signal (an active IRQ with GIE still set would perhaps crash the system before the boot code can do anything)
    Then the boot code can kick-in and do its job. Which takes the said 1-3ms, depending on how much is to do (POR or PUC init)

    Anything else won’t make sense, as it then could happen that as long as BOR is active, the port pins still have an active output state. Or, if power was really down, could have a random state.  Which would be bad not only regarding energy waste.

**Attention** This is a public forum