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.

MSPM0G1107: Timing difference/ tradeoffs for using fastwake

Part Number: MSPM0G1107

Tool/software:

Hello,

I see in the datasheet we quote wakeup times from stop mode with fastwake enabled. 

What's the timing with fastwake disabled? 

Also, are there any tradeoffs of using fastwake like additional current consumption? 

Munan

  • Hi Munan,

    In the device datasheet in section 7.8, the wake times listed for each section actually just refer to the standard wake times. You can see the first section lists the wakeup timing for each low power mode, including the wake from shutdown when using fast boot vs without using it. The next section of the same table shows the asynchronous fast clock request timing. Below that, you can find the full startup time normally, and with fast boot enabled. The final section shows some of the NRST timing.

    The tradeoff when you enable fast boot is also listed in the device technical reference manual. To give a short summary, when fast boot is enabled, some of the BSL invoke conditions are not tested. Additionally, the application CRC check is bypassed.

  • Hey Dylan,

    Doesn't that timing section have a footnote that explicitly says that this is the timing with fastwake=1?

    And I want to be clear that I'm only asking about FASTWAKE where you're coming up from a Standby or STOP mode rather than from SHUTDOWN. The datasheet and TRM isn't clear on exactly what FASTWAKE does to make the device wake faster from those low power modes.

    So does fastwake just mean that this logic asserts an asynchronous fast clock request to wake up slightly faster?

    Munan

  • Hi Munan,

    Sorry about that, I mixed things up here, I see what you are saying now. It looks like we don't list that information in the datasheet so I'll write a simple test program in the next few days to check these times for you. 

    My understanding is of the process is like you described: the GPIO will generate an asynchronous fast clock request when waking up to speed the process up.

    Reading through our descriptions of the asynchronous fast clock request, it looks like the tradeoffs are that some of the clock configurations that you may have set won't be asserted during that request.