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.

MSP430FR6879: The concept of capture timing and the relationship between DMA and PMM29

Genius 5300 points
Part Number: MSP430FR6879

Hi experts,

The following questions about TimerA and DMA could not be confirmed from the document, so I would appreciate it if you could tell me about them.

[TimerA]
The time chart for the capture mode with SCS=1 is shown in "Figure 25-10. Capture Signal (SCS = 1)" in User's Guide (Rev. P).

Q1: If SCS = 1, is it correct that the capture is triggered by the falling edge of the timer clock?

Q2: Assuming that the capture is triggered on falling edge, is the following idea correct?
If CCI fluctuates at the timing of timer clock = HIgh, the count value at that point will be captured.
If the CCI changes at the timing of timer clock = Low, the count value at the state advanced by one clock cycle is captured.

Q3: If SCS = 0, is it correct that the capture is triggered at the same time as the timing of CCI change?

[DMA]
Currently, the FRLPMPWR bit is set to 0 in order to respond to the errata PMM29. In this case, it is stated that a wait time of "twake-up workaround = twake-up LPM3 + twake-up FRAM" is required at startup.

Q4: Does this concept of wait time also need to be taken into account when DMA transfer is triggered by a timer during LPM (no interrupt processing is used)?
Note that the source of the DMA transfer is a variable on the SRAM and the destination is the POUT register of the IO port.

Best regards,
O.H

  • Hi O.H,

    Regarding your questions,

    1. The capture can be triggered by rising, falling, or both rising and falling edges. This can be set with the CM (capture mode) bits in the TAxCCTLn registers.
    2. The following idea seems correct based on "Figure 25-10. Capture Signal (SCS = 1)" and if the trigger is set to falling edge.

    3. I'm not sure about this. Based on the CM bits, captures can only be triggered on the rising, falling, or both rising and falling edges of signals.

    4. You may need to take this into account even if the DMA transfer doesn't involve FRAM as a source/destination addresses. Here's a thread where the user was getting an unexpected FRAM power up due to an IFG arrival [link].

    Thanks,

    Urica Wang

  • Hi Urica Wang,

    Thanks for the reply.

    1. The capture can be triggered by rising, falling, or both rising and falling edges. This can be set with the CM (capture mode) bits in the TAxCCTLn registers.
    2. The following idea seems correct based on "Figure 25-10. Capture Signal (SCS = 1)" and if the trigger is set to falling edge.

    I thought the CM bit in the TAxCCTLn register was for setting the edge of the signal input to the CCI pin, but does that mean it also affects the edges of Capture and Timer clock?

    "Figure 25-10" shows that the CCI signal edge is set to the rising edge (CM=01b), but the actual Capture timing seems to be set to the falling edge of the Timer Clock.

    4. You may need to take this into account even if the DMA transfer doesn't involve FRAM as a source/destination addresses. Here's a thread where the user was getting an unexpected FRAM power up due to an IFG arrival [link].

    Due to the complexity of the content, I will check this once.

    Best regards,
    O.H

  • Hi O.H.,

    You're right. The CM bits description in the "Capture Mode" section of the User Guide make no mention of the edges of the capture and timer clock. I found this E2E thread which supports the idea that when SCS = 1, the capture is triggered by the falling edge of the timer clock [link].

    Thanks,

    Urica Wang

  • Hi Urica Wang,

    I am a colleague of O.H.

    I have some additional questions.

     

    [Question1]

    User Guide 26.2.4.1 Capture Mode states that "TI recommends operating with SCS = 1."
    Can you tell me the disadvantages of operating with SCS = 0?

     

    [Question2]

    You may need to take this into account even if the DMA transfer doesn't involve FRAM as a source/destination addresses. Here's a thread where the user was getting an unexpected FRAM power up due to an IFG arrival [link].

    The target of DMA transfer requires accuracy, and we are currently approaching it by using DMA to reduce the number of cycles.

    For this reason, the startup time of FRAM has a fluctuation range between typ and Max, so I would like to avoid it if possible.

    As a workaround, we are considering the following conditions and countermeasures.

    - Use LPM0 and LPM3.
    - When using DMA, it is assumed to start from LPM0. (This avoids errata, as in WorkAround 1.)
    - Set FRLPMPWR before migrating to LPM0.
    - Clear FRLPMPWR before migrating to LPM3.

    Under this condition, what is described in WorkAround 3 (clear FRLPMPWR at the beginning of the code) is different.

    Is it possible to adapt as WorkAround 3 of PMM29 even if the corresponding bit is dynamically switched as described above?

    Best regards,

    Koki

  • Hi Koki,

    Regarding your questions,

    1. The disadvantage of operating with SCS = 0 (capture signal is asynchronous to the timer clock) is that it may cause a race condition.

    2. The adapted workaround that you've described above should be ok if you make sure to clear FRLPMPWR before entering LPM2/34. The erratasheet suggests to implement the workaround at the beginning of the code to cover that case (clearing FRLPMPWR before entering LPM2/3/4) in general.

    Thanks,

    Urica Wang

  • Hi Urica Wang,

    Thanks for the reply.

    The disadvantage of operating with SCS = 0 (capture signal is asynchronous to the timer clock) is that it may cause a race condition.

    I don't really understand the race condition. I would appreciate it if you could explain in detail.

    Best regards,

    Koki

  • Hi Koki,

    I can't find supporting documentation on the exact details of the race condition, but based on this thread [link] and the note "Modifying Timer_A registers" in the "16-bit Timer Counter" section in the User's Guide, my guess is that you may not get a reliable reading of the TAxR register.

    Thanks,

    Urica Wang

  • Hi, Urica Wang

    Thank you for your reply. I would like to clarify this part because it may be used with SCS = 0.

    I checked the link, but couldn't fully understand it. What is the conflict with "race condition"?

    For example, let's talk about the case of SCS = 0.
    If the capture occurs just between n-1 and n, the CPU does not know whether it is judged as n-1 or n, and I think that the value may be invalid.

    Is it correct to understand that this is called a "race condition"?

    If the recognition is different, please tell me what kind of content is the disadvantage when using SCS = 0.

    Thanks,

    Koki

  • Hi Urica Wang,

    Do you have any update?

    Thanks

     KOKI

  • Hi Koki,

    Thanks for your patience. I have confirmed with the experts that your understanding is correct. With SCS = 0 and based on your diagram above, you may get N or N - 1. If you are dependent on these values, this could throw your program off. With SCS = 1, you will get more consistent results of N every time you capture.

    Regards,

    Urica Wang

  • Hi, Urica Wang

    Thank you for taking the time to check with the expert.

    Regards,

    Koki

**Attention** This is a public forum