ETPU - Interrupting of Execution of a Thread

[mertk]

Hello,

I am working on eTPU - AN 4907 Engine Control demo using by ASH WARE eTPU2+ Development Tool.

Firstly, I want to describe my situation and then I will ask my questions.

My situation: I added a new function that execution time of its approximately equals to 3 microseconds into CRANK. Because of the new function, execution times of threads of CRANK function are too long. It makes me wonder about execution of the threads of CRANK. In my cases, CRANK threads must not interrupted by the HSR, LSR or other service requests of SPARK and FUEL channel threads. CRANK thread must finish its execution.

Question-1: I wonder that what happens if we interrupt a thread while it is executing? Here what I found in order to find the answer. Is there anything I'm missing or wrong? 

In order to find answer of Question-1, I read ETPURM (see Chapter 7-1) and MPC5642ARM (see Page 643) documents. MPC5642ARPM says the below one:

Once a Thread begins, its execution cannot be interrupted. A Thread normally finishes when an END microinstruction is executed.

ETPURM say the below one:

See Chapter 7-1:
Once a thread begins, its execution cannot be interrupted by another function. Execution can be halted by the host. A thread finishes when an END microinstruction is executed.

See Chapter 10-1:
Halt is a microengine state where it stops executing during a thread, or does not start executing a scheduled thread from idle state. While idle state is entered from END execution without any other scheduled thread, microengine enters halt state by any of the following events:
-  Execution of the HALT microinstruction (software breakpoint).
-  External halt request through the debug interface
-  The other engine enters halt state and they are configured to halt simultaneously (bit HTWIN is asserted via the Nexus interface).
-  Occurrence of any of the hardware breakpoint conditions. 
-  Execution of a single-step microinstruction: microengine returns to halt state after executing a single microinstruction while in halt state. 

Regarding the above information, I understand that an execution of a thread cannot be interrupt by anything, however it can be halted by the host. I think halting is not our concern in this topic because of I am wondering the situations in release, not debug and the events that make the microengine halted are carrying debug purpose. 

Question-2: Can the feature of interrupting a thread be changeable or configurable with any registers? Is there any register that I allow the thread to be interrupted? 

I checked ETPURM and MPC5642ARPM and I couldn't find any register in order to configure the feature about interrupting a thread. What I was expecting is I could select an execution of thread can be interrupted or not. Is there any register that I can allow the thread to be interrupted? 

Question-3: Is it possible to do that a channel cancels the others channel's service requests without LSR or HSR? I need to know that can SPARK or FUEL service requests cancel the CRANK threads without triggering CRANK channel by LSR or HSR? 

I know that a thread that is triggered by the LSR or HSR in a channel can cancel the next thread that is in the same channel. See my other question here: ETPU-HSR-when-Match-Service-FUEL-and-SPARK However I wonder that can SPARK or FUEL service requests cancel the CRANK threads without triggering CRANK channel by LSR or HSR? 

I tried to explain my questions in an easy to understand way. I hope you can help me. 

I am looking forward to your answers. 

Best Regards,

Mert.

[mertk]

Hi @davidtosenovjan and @johndiener 

I really appricate for your helps. Thank you. 

Hi John,

how do you know your crank thread is taking too long - what kind of failures are you seeing?

Execution time of the crank thread is about 2 microseconds without filter. Execution time of the same crank thread is about 5 microseconds with the filter. Thus, I described the change in the execution time as crank thread is taking too long. Furthurmore, I don't see any failures.  I did some tests and researched to be sure about my design. However, I was worried about is there anything I may missing about this topic. Thanks to your answers, now I know there is no missing about this topics.

Thank you for your helps. 

Best Regards,

Mert. 

[johndiener · Accepted solution]

Hello Mert,

As David notes, eTPU threads cannot be interrupted by other threads - they run to completion. This is a fundamental part of the eTPU execution model. With regards to Q3, "cancelling another channel's service requests" is perhaps not a very good way to describe what is possible in the eTPU. Once events have occurred on a given channel (HSR, LSR, matches, transitions detections) it would be very hard (or impossible) for another channel to reliably "cancel" the service request by clearing the source event latches. In the case of HSRs, they cannot be cleared from the eTPU at all. For the other events, an eTPU channel has no real control over when it gets serviced, when in competition over activation, and thus somehow having a channel run before the channel in question gets serviced, is just not reliably possible. One thing that can be done is disabling a channel's matches, or disabling a channel's transition detection, from another channel. Such code could look something like this:

int24_t tmp = chan;
chan = crank_chan; // switch to channel of interest so channel hardware commands apply to this new channel

// could disable matches
channel.MRLE = MRLE_DISABLE; // disabling pending matches on crank_chan
channel.MRLA = MRL_DISABLE; // clear out any match request latches that haven't been serviced yet
channel.MRLB = MRL_DISABLE;

// could disable transition detection
channel.IPACA = IPAC_NO_DETECT; // disable transition detection
channel.IPACB = IPAC_NO_DETECT;
channel.TDL = TDL_CLEAR; // clear out any transition detection latches that haven't been serviced yet

// a few other possibilities ...

chan = tmp; // point at the original channel again

One other thing. Going back to the start of your post - how do you know your crank thread is taking too long - what kind of failures are you seeing?

[davidtosenovjan]

As I know a thread cannot be interrupted.
It follows logically from the fact that worst case latency is being calculated according length of threads.

Regarding point.3, I guess @johndiener could tell more info to this topic.