
Architecture of the eTPU Channel
Understanding the eTPU Channel Hardware, Rev. 0
Freescale Semiconductor
13
{
SetupMatchA(Interrupt_Angle); //this sets the start of the pulse
OnMatchAPinNoChange();
Next_Match = Pulse;
}
else // if Next_Match == Pulse;
{
SetupMatchB(Pulse_Start_Angle); //this sets the start of the pulse
OnMatchBPinHigh()
SetupMatchA(Pulse_Start_Angle + Pulse_Width); //sets the end of the pulse
OnMatchAPinLow()
}
if (MatchB_TransA)
{
ClearMatchBLatch();
OnMatchBPinNoChange()
Next_Match = Interrupt;
}
/* ...continue... */
In Example
4
, the user wishes to use the match registers to produce a pulse at regular intervals, but
interleave the pulses with a channel interrupt. The expected order of the threads is to execute the MatchA
on the rising edge of the pulse, followed by MatchB on the falling edge, followed by another MatchA on
the interrupt with no pulse. The variable Next_Match toggles between Pulse and Interrupt to keep the states
in order. This is a good example of using a single channel to handle multiple, non-conflicting tasks.
The code may operate as expected under most conditions. However, if the Pulse_Width variable is set to
a low number, and the speed of the Angle Clock (engine speed) is fast enough, and there are other channels
sharing the eTPU, it is possible that after the rising edge MatchB occurs but before the Scheduler can grant
the service request, the falling edge MatchA may occur. If this happens, the falling edge would be
processed before the rising edge, and the variable Next_Match would not be changed before the pulse is
set up again. The result is a rather bizarre operation for one cycle, and since the conditions might be
improbable, the bizarre pulse might appear rarely and look like a random event.
There are a number of ways to solve the problem, of course, but one contributing cause was the assumption
that the matches would be serviced in order of occurrence. When it is possible that two service requests
occur within a short time of each other, the user must plan for the orderly execution of the threads.
In the entry vector tables, the channel conditions MatchA_TransB and MatchB_TransA each have entries,
but there are also entries for both conditions together. In the example, the user needs to ensure that when
both conditions are satisfied, the MatchB_TransA thread is taken. This can be done in two ways.