PIT DMA trigger details

[mjbcswitzerland]

Hi All

I am trying to work out some details about the PIT's DMA trigger timing, specifically:
- can it be pending?
- can pending DMA be cleared to avoid unwanted triggering?

While working on timed DMA driven UART operation for DMX type applications, where accurate inter-character spacing can also be of importance for accurate timing, there is one behavior that is not defined exactly which I would like to fully understand.

Using a PIT timer as DMA trigger transmission characters are copied at an accurate periodic rate to the UART's data register (this works on LPUARTs but not on other types, but that is another topic which I will report on). The result is a stream of tx data with exact delays between each character - eg. in scope shot below. There is no CPU overhead since it is self-timed by the PIT for the programmed number of transfers.

There is a reference before the first character transmission at the time point when the PIT was started. Then the free-running PIT periodically triggers the next transfer with the same period..

However in some circumstances the behavior is not identical (the first time the PIT is used after a reset or after being used for other purposes). The timing can look like the second image below:

In this case the first DMA trigger fires immediately when the PIT is configured, rather than when it first times out. Once the PIT is free-running the inter-character spacing is as expected.

What is not clear is why the PIT generates a DMA trigger sometimes when configured/enabled and sometimes only when its fist times out. It is as if there is a DMA trigger 'pending' when enabled.

Does anyone have any knowledge about how this could be controlled (eg. by somehow clearing pending DMA triggers before the can fire)?

Regards

Mark

P.S. I put a reference binary at http://www.utasker.com/kinetis/FRDM-KL27Z.html#UART_TIMER showing the behavior (on KL27 LPUART) as well as giving so additional information concerning the UART mode.

[bobpaddock]

I use PIT/DMA3/TPM to make sounds accurate to the nano-second (Never underestimate the stupidity of politicians writing technical regulations that become laws).  In the MKL27 that I'm using I ran into these things.  

What it takes to clear:

ATOMIC_BLOCK( ATOMIC_RESTORESTATE )
{
TPM_SC = 0UL; /* PWM Off */
PIT_TCTRL0 = 0UL; /* PWM Duration timer off */
PIT_LDVAL0 = 0UL;
DMA_DSR_BCR3 = DMA_DSR_BCR_DONE_MASK; /* Clear all DMA status and error bits */
DMA_DSR_BCR3 = 0UL; /* 'Done' must be cleared to configure the DMA */
DMA_DCR3 = 0UL;

PIT_TFLG0 = PIT_TFLG_TIF_MASK; /* Clear flag so there is no immediate IRQ when PIT is enabled */

}

The order that PIT_MCR is set is significant.

/* Periodic Interrupt Timer (PIT) configuration. Used for TPM tone duration control: */

/*
* Errata mask 1N71K e7914: PIT: After enabling the Periodic
* Interrupt Timer (PIT) clock gate, an attempt to immediately
* enable the PIT module may not be successful.
*
* Description: If a write to the PIT module enable bit
* (PIT_MCR[MDIS]) occurs within two bus clock cycles of enabling
* the PIT clock gate in the SIM_CG register, the write will be
* ignored and the PIT will fail to enable.
*
* Workaround: Insert a read of the PIT_MCR register before writing
* to the PIT_MCR register. This guarantees a minimum delay of two
* bus clocks to guarantee the write is not ignored.
*

/*

/* Do three times to make sure it really happens, as once was not getting it done: [There is an internal timing race] */
(volatile uint32_t) PIT_MCR; /* Force read as errata workaround */
PIT_MCR = PIT_MCR_FRZ_MASK; /* Enable timer and freeze timer when debug mode, This field must be enabled before any other setup is done */

(volatile uint32_t) PIT_MCR; /* Force read as errata workaround */
PIT_MCR = PIT_MCR_FRZ_MASK; /* Enable timer and freeze timer when debug mode, This field must be enabled before any other setup is done */

(volatile uint32_t) PIT_MCR; /* Force read as errata workaround */
PIT_MCR = PIT_MCR_FRZ_MASK; /* Enable timer and freeze timer when debug mode, This field must be enabled before any other setup is done */

Also do this right before enabling the PIT as configuring it may set the flag, you do mention this:

        PIT_TFLG0 = PIT_TFLG_TIF_MASK;          /* Clear flag so there is no immediate IRQ when PIT is enabled */

Also the DMA must be loaded and configured before the PIT.

Someday I'll post some code based this DMA/PIT/TPM the that plays Nokia Ring Tones (RTTTL).
I like to play 'Mission Impossible' on changes of schedule or yet new hardware bugs with the chips... :-/

[xiangjun_rong]

Hi, Mark,

Is it possible that the TIF bit is set in PIT_TFLGn reg before you enable the PIT? I suspect that PIT triggers DMA immediately with the TIF set when you you enable the PIT.

Pls clear the TIF bit by Writing 1 to this flag before you enable PIT module, pls have a try.

Hope it can help you.

BR

Xiangjun Rong

[mjbcswitzerland]

Hi Xiangjun 

This is the code used to start the PIT:

        ptrCtl->PIT_TCTRL = 0;                                                           // disable PIT so that it can be re-triggered if needed

        ptrCtl->PIT_LDVAL = PIT_settings->count_delay;                   // load interval value
        ptrCtl->PIT_TFLG  = PIT_TFLG_TIF;                                     // clear pending interrupts

        ptrCtl->PIT_TCTRL = PIT_TCTRL_TE;                                   // start PIT without interrupt

When used for PIT interrupt it never triggers an interrupt too early. In this case the interrupt is not enabled of course.

I had also tried clearing the TIF after the PIT was started but before the DMA channel was enabled but it also didn't change anything.

Regards

Mark