MPC5634 eTPU Spark

[208677262]

• Hi, I had a problem using ETPU's Spark feature.

When spark output was high, crank signals were suddenly lost and Spark was not automatically shut off.How do I set Spark to turn it off.

• Please check the attached pictures for yellow crank signals and purple Spark signals.

thanks.

[turgay_kale]

Dear Feng,

I had come across with this problem before, in the spark function (of NXP's standard engine control set) there is no default setting of spark output if crank signal is lost. You may set to default level when this condition is occured as John has told.

/* NXP engine control set (ETPU) -- etpuc_spark.c */

void SPARK(struct SPARK_CHAN_PARAMS spark_local)

{
   if ((hsr == SPARK_HSR_INIT) || (lsr == 1))

   {

      ..

      /* Deactivate spark output if crank signal is lost and engine is not synchronized. */
      if (eng_pos_state == ENG_POS_SEEK)
      {
          if(cc.FM0 == SPARK_FM0_ACTIVE_HIGH)
         {
             channel.PIN = PIN_SET_LOW;
         }
        else
        {
            channel.PIN = PIN_SET_HIGH;
        }
    }

   ..

}

You can get the source code of NXP's standard engine control set (ETPU) and API source code at https://www.nxp.com/docs/en/application-note-software/AN4907SW.zip 

Regards,

[johndiener]

Andrei is correct, the spark channels should be in the crank link list, to which link requests get issued when a stall is detected.  However, as the OP noticed, if the stall occurs while a spark is active (during dwell time, before end angle), the spark pin remains stuck at active level.  This is true even if the spark channel is in the link list - the spark gets re-initialized, but the initialization code leaves the pin state untouched. It looks like:

A small patch to the spark init eTPU code, which sets the pin level to the inactive state, results in better behavior:

I don't know yet how to work around this without patching the eTPU code.  I had originally though the max dwell time should kick in and shut off the pulse, but it turns out given the channel mode being used, if the TCR2 counter (angle) never reaches the spark end angle in this case, max dwell time never kicks in.

-john

[208677262]

Hi. John Diener.

My eTPU code is generated by CodeWarrior ETPU Function Selector, where should I change it?

Attached is the etPU code file.

Best Regards.

[turgay_kale]

Dear Feng,

You can get the source code of NXP's standard engine control set (ETPU) and API source code at https://www.nxp.com/docs/en/application-note-software/AN4907SW.zipthen modify it as you wish. You have to build (compile & link) ETPU source code with an ETPU compiler to generate etpu_set.h for your project.

Regards,

[208677262]

Ok, I will try to modify it. Thank you for your help.

Best Regards.

[AndreiC]

Hey John, since I’m seeing this same action with FUEL leaving the injector open on stall, could it be an issue with CRANK not sending the links, or just a bad TPU code idiom where a bunch of the functions don’t go to their inactive state since they all share the same code?

I think we had talked about this before, since my CRANK isr had code to disable my FUEL channels, but that also left the injectors open. One of my jobs in the next week was to raise this issue here and find a work around that actually worked reliably. 

[johndiener]

When FUEL receives a link, unlike SPARK it explicitly sets the pin state to inactive (note that code running to capture image below has SPARK patch):

If CRANK properly detects a stall, then it will issue links (up to 16 unique).  Is CRANK for sure detecting a stall?  Are your FUEL channels on the same eTPU engine? - if not, the link values need to be carefully programmed for cross-engine communication.

-john

[AndreiC]

Yes the FUEL functions are running on the same TPU engine. But we have seen injectors left open. 

Which parameter of the FUEL channel config is used to control the inactive state?

Feng Yang, NXP has to rev the code so you can download the corrected bundle. 

[208677262]

Hi,  Andrei Chichak .

The eTPU code was recently generated using CodeWarrior ETPU Function Selector.

[johndiener]

If you can work with the eTPU source code, the patch to the SPARK initialization code is just a few lines:

Otherwise, as mentioned, an option is to wait until the code gets rev'd on the NXP eTPU function selector. I am sending the above info to an NXP contact, so perhaps they will do so or identify a more appropriate solution.  May or may not make sense for you, but also available is the ASH WARE build of the AN4907 code, which has been updated and can be downloaded via a link on the Software - Website - Ashware webpage.

-john

[208677262]

I do not have the source code of eTPU, thank you very much for your help.

Best Regards.

[AndreiC]

In theory, CRANK has some parameters in the crank_instance, .link1-4 where you can list 4 channels per .link entry and when your engine stalls, it will send a link to the listed channels and those other channels get reset.

But, when I get out from a weird processor crashing bug, I'll be putting together some code to show that we couldn't get this to work either. In our case I am using CRANK to send links to a bunch of channels that are controlling injectors.

We have seen the injectors left on when CRANK desynchronizes. I tried putting in some belt and suspender code into the CRANK ISR and it's not going well. Especially when the tpu says that the engine RPM is still high when in a stall resync.

So, try the .link values in the crank_instance as documented in AN4907/AN4908, but check the results. The documentation of the link action is skimpy to non-existant, and we've had problems with it actually working.

A