Help with eTPU IC function interrupts on MPC5634M

[AndreiC]

I'm working with the automotive function set on an MPC5634M (crank/cam/fuel/knock) and I seem to have control of my signals where the crank and cam sync and I'm able to generate fuel and knock signals that show up in the correct place with the correct width on an oscilloscope. Interrupts firing properly. Just works.

For the next part of my project I need to detect some incoming signals that are timed to the crank, so I'm using the IC function to count pulses, give me the position of those edges and generate an interrupt when N edges go by.

The problem that I'm having is that I don't seem to be able to generate interrupts on channels greater than 23. I started by fighting with channel 26 for a while, I could not get an interrupt to fire. Then moved to 16 while writing this question and things started working. I've tried a few more pins in-between, 25 no, 22 yes, 23 yes, 24 no.  OH NO could it be a 24 bit encoding thing?

I took a look at the CIER in the eTPU in the debugger and it SEEMS to have 31 bits and the appropriate bits for channels 23 and 24 are set. But IC will only generate interrupts for channels <= 23.

Any ideas?

The function microcode was generated on https://www.nxp.com/webapp/etpu_cw/ . My set consists of crank/cam/fuel/knock/ic/oc.  The development environment is the latest version of S32DS using gcc. My board is a pair of TRK-MPC5634M boards purchased recently.

Thanks,

Andrei (from the Great White North)

[AndreiC · Accepted solution]

I got a message from some very helpful people within NXP. 

TPU pins 24-29 go through a multiplexer with the DSPI unit and the DSPI signals are selected by default.

Altering bits in SIU.ISEL8 connected the TPU pins to the pads.

As for the IC function giving odd values from read_final_time, that's still a mystery.

Thanks for your attention.

A

[AndreiC]

And the answer to the read_final_time value being borked was also supplied by someone within NXP.

The value is a cumulative value from TCR2 that does not reset as I assumed it did.

To get the cycle value out, there is a function in the CRANK function sample code called fs_etpu_crank_get_angle_reseting. This function is not provided in the CRANK interface code when you generate a microcode set on the web site.

[AndreiC]

I thought I'd also add that the value returned by fs_etpu_read_final_time is way out of range.

I'm using TCR2, which should be in the range of 0 - 71999  (a 720 degree engine cycle) but the values showing up in the eTPU parameter memory and returned by read_final_time is a very large 32 bit value.

Something tells me that the microcode for IC may not have been converted properly for eTPU2, or I'm doing something very wrong.

Is there anybody here from NXP/Freescale/Motorola that is in the PPC automotive processor TPU group?

Thanks,

A