• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 345 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.

MSPM0G3507: GPIO fastwake functionality requires minimum pulse time

Florin Popescu
Prodigy 90 points
Part Number: MSPM0G3507
Other Parts Discussed in Thread: MSPM0L1306

Hello!

We have an external chip which sends a really short duration high pulse on a GPIO of the microcontroller, and we have configured the microcontroller to wake up on rising edge of that pin. The microcontroller is in STANDBY1 mode during sleep, using internal RC clock at 32MHz in RUN0 otherwise. The pulse is about 3.2 us long and sent once every 100ms. The input pin on the microcontroller is set in standard mode, interrupt trigger on rising edge, using fast wakeup functionality. The microcontroller however doesn't reliably wake up on this pulse, instead only waking up sporadically, sometimes for seconds in a row, other times it misses some pulses.

We have some control over the length of that pulse and have seen that by doubling the pulse length (6.4us), the microcontroller wakes up 100% of the time.

I would like to know if there is some minimum required pulse time for a fast wake up to be correctly processed. I don't know if we could expect this to work under all conditions or if there is some clock/temperature dependency.

Is this information already available somewhere in the datasheet?

Thank you,

Florin POPESCU

  • 0
    TI__Guru 56685 points

    Hello Florin,

    The TRM for this device will have a note  about this and some additional information about the synchronization filters.The TRM is not quite available for this family, but a similar note can be found in the MSPM0L1306 TRM in the GPIO chapter. The summary of the note is: when using fastwake ability, the minimum pulse length for asynchronous wakeup has to be greater than the asynchronous fast clock request wake time. Currently, only typical values for this latency time are given, so I would add some margin to that number. 

    Additional information within synchronization filter section:

    Sampled input without filtering (the minimum reliably detected pulse width is one ULPCLK cycle due to synchronization of the pin state with ULPCLK +Delay time from edge of asynchronous request to first 32MHz MCLK edge in case of fast wake enable for STANDBY0/1, STOP1/2 and SLEEP2 modes)

  • 0 in reply to Jace H
    TI__Mastermind 28157 points

    Hi Florin,

    Further to Jace's response, let me add that the "Delay time from edge of asynchronous request to first 32MHz MCLK edge" parameter may be found in the device datasheet. When coming from STANDBY1 mode, this delay is typically 3.2 us. I will investigate on what the maximum delay is.


    Best regards,
    François.

  • 0
    Prodigy 90 points

    Thank you both for your responses! Indeed I did not have the L series TRM but was looking at a draft version of the G series one.

    To sum up, I would need the pulse to be at least 1 ULPCLK cycle + the delay to first 32MHz clock edge = 30.51 + 3.2 = 33.71 us typical. Is my understanding correct?

    For ULPCLK the datasheet provides the accuracy over full temperature range, so I can get a worst case figure from that.

    Please come back to me once you have the worst case tDELAY for STANDBY1.

  • 0 in reply to Florin Popescu
    TI__Guru 56685 points

    Hello Florin,

    Unfortunately at this time, we don't have a max specification of the tDELAY parameter, only a typical.