• State
  • Locked Locked
  • Replies 16 replies
  • Subscribers 81 subscribers
  • Views 538 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.

MSP430FR5959: Boot-Up Expected Timing

Luke
Expert 4080 points
Part Number: MSP430FR5959


Tool/software:

Hi team,

I’m reaching out in regards to ‘Boot-up’ timing on the MSP430FR5959IRHAT. We are seeing that once it is powered, it takes ~220ms for code to start running, and I just wanted to verify that with the datasheet/app notes.

In the user guide, there are references to a Brownout Reset (BOR), a Power-On Reset (POR), and a Power-Up Clear delay (PUC), which would happen sequentially upon powering on the micro and before code begins running. However, I cannot find specified timing of these delays anywhere other than the values ranging from a few uS to about 1.5ms in Table 5-9 of the DS. Are you able to specify expected timing for these delays, along with any other sequential power up delays that we could expect? Is ~220ms around  the expected timeframe?

For further info, we are measuring 220ms between when the Vcc rail reaches 3V and when the MSP430 begins toggling a GPIO pin for an external watchdog timer. It also seems like there is a significantly less power consumption during this 220ms period. My initial thought was that 220ms seems quite long and could be the crystal start up time or other initialization delays in the code? 

Best,

Luke

  • 0
    TI__Mastermind 18652 points

    Hi Luke,
    How are you running your code? Sometimes the computer you use can add delays to the code running.

    Best Regards,

    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    TI__Expert 4080 points

    Hi Diego, 

    I appreciate the quick response! We’re capturing this delay through measuring comparing when the Vcc line boots to >3V and comparing that to when our GPIO line begins toggling (to poke the external watchdog timer), which is one of the first things that happens in our code. I can send over a scope capture if this could be helpful, but it seems like there is a ~220ms period between when the power bus is up to voltage, and when the code GPIOs activate. You can also see on the voltage rail that the load increases when the GPIOs begin toggling, which I would assume is partially from driving the GPIOs, but also likely because it indicates the code is beginning to be ran.

    Thanks,

    Luke

  • 0 in reply to Luke
    TI__Mastermind 18652 points

    Hi Luke,
    I would recommend attaching the scope capture so I can analyze it and see if I can find anything weird with it. Just to ask, what is the code supposed to do, is there any commands running before the GPIO toggles?

    Best Regards,

    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    TI__Expert 4080 points

    Hi Diego,

    Customer will be able to provide a scope capture on Monday once back in the office. 

    Since a power up delay was expected, the toggling of the watchdog GPIO was prioritized. They will double check that there are not other functions running beforehand, but I wouldn’t expect any of them to be significant.

    This application is for an NFC device that handles a proprietary protocol and security functions.

    Best,

    Luke

  • 0 in reply to Luke
    TI__Mastermind 18652 points

    Hi Luke,
    Thanks for letting me know. I'll wait for further information on Monday.

    Best Regards,

    Diego Abad

  • 0
    Guru 100715 points

    I tried an experiment with an FR5969 (Launchpad): I raised one GPIO in _system_pre_init, and another as the first line of main. I measured:

    1) 3.0V on VCC -> _system_pre_init: 0.536ms

    2) 3.0V on VCC -> main: 0.580ms

    I then inserted an 1800-byte variable (.bss) so the startup initialization had some work to do. For that, I measured:

    3) 3.0V on VCC -> main: 22.8ms

    So C initialization could be one element, but that still isn't 220ms. Are you doing anything else before the GPIO?

  • 0 in reply to Bruce McKenney
    TI__Expert 4080 points

    Hi team,

    Attached are the scope captures.

    ‘Float Time’ is shown as the state from when Vcc (Ch1) reaches a stable voltage of ~3.3V to when the Watchdog Timer signal (ch2) moves from a floating voltage to a 0V. This in an NFC system so the rail takes a bit to stabilize.

    ‘Load Time’ is shown as the time between when the Watchdog Timer signal is 0V to when it begins toggling. This shows ~20ms, which lines up with the 3rd estimate you provided below. You can also see that the voltage rail begins to fluctuate and has spikes past this time, so I believe that is good reason to believe that’s when the initialization is complete and the code is running.

    Thanks,

    Luke

  • 0 in reply to Luke
    TI__Mastermind 18652 points

    Hi Luke,
    It seems that the code previous to setting the Watchdog Timer is somehow stalling the the time. Can you ask your customer more information about what code do they have before it?

    Best Regards,

    Diego Abad

  • 0 in reply to Luke
    TI__Mastermind 18652 points

    Hi Luke,
    Any updates on the customer's situation?

  • 0 in reply to Diego Abad Sajamin
    TI__Expert 4080 points

    Hi Diego,

    I have reached out to the customer about more information and will let you know when I hear back. 

    Best,

    Luke

  • 0 in reply to Luke
    TI__Mastermind 18652 points

    Hi Luke,
    Awesome. Let me know when you further help.

    Best Regards,

    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    TI__Expert 4080 points

    Hi Diego,

    The startup sequence of their code is the following:

    1. Disable internal Watch Dog
    2. Disable interrupts globally
    3. Initialize the clock
    4. Configure I2C pins
    5. Enable global interrupts globally
    6. Set External Watchdog Timer GPIO pin as output
      • This is when Channel 1 of the scope capture shows the voltage go to ~4V

    They are interested in why the voltage on Channel 1 hangs at 1V, as if it is uninitialized, for such a long time. Once the voltage goes to ~4V, they understand the timing. The above sequence should be extremely fast, could you help us understand why it takes so long between power-up and Step 6?

    Best,

    Luke

  • 0 in reply to Luke
    Guru 25105 points

    A general description of what you think is happening is much less useful than the actual code. For example, "Initialize the clock" can cover a lot of things. Such as the typical startup  time for the LFXT. Which all by itself can exceed 200ms.

  • 0 in reply to Luke
    TI__Mastermind 18652 points

    Hi Luke,
    David is correct in regard of the initialization of the clock. Is there a way to share the customer's code? Also, are they using an external crystal? 

    Best Regards,

    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    TI__Expert 4080 points

    Hi David, Diego,

    I have requested the customer share their code as I understand this would be much more useful. I will let you know when I hear back.

    Thanks,

    Luke

  • 0 in reply to Luke
    TI__Mastermind 18652 points

    Hi Luke,
    Sounds good. I'll look forward to it.

    Best Regards,

    Diego Abad

**Attention** This is a public forum