ETPU New API AN4907 CRANK ERROR clarifications

cancel
Showing results for 
Search instead for 
Did you mean: 

ETPU New API AN4907 CRANK ERROR clarifications

Jump to solution
846 Views
arjunraveendran
Contributor III

1. I am using AN4907 and AN4908 based etpu library for engine management control using MPC5634M ECU. I am able to get crank sync and obtain all pulses: spark, fuel as per requirement. However, when logging CRANK ERRORS, i am getting some undesired signal values (108,-116 etc) which are not present in API document.(please see attached image and log file).

Can you please help me on this regard.

 

2. i have been using AN4907 ver 1. i see now there is a rev2. could you link me to corresponding AN4908SW file with the changes in API, i am unable to find it online.

 

Thank,

Arjun.

0 Kudos
1 Solution
830 Views
johndiener
Contributor IV

Hello Arjun,

The crank error flags are accumulated (bitwise-ORed) in the crank eTPU software and then cleared every time the fs_etpu_crank_get_states() API is called. Thus the two values you mentioned work out to several accumulated errors: 108 => 64 (TIMEOUT_AFTER_GAP) + 32 (TIMEOUT_BEFORE_GAP) + 8 (STALL) + 4 (TIMEOUT)  and  -116 => 140 (unsigned int8) => 128 (TOOTH_IN_GAP) + 8 (STALL) + 4 (TIMEOUT).

I have not looked at your crank signal data nor tried to simulate it, but I would assume it is such that it results in a cascade of errors that net error values of 108 and 140.

John Diener

View solution in original post

4 Replies
831 Views
johndiener
Contributor IV

Hello Arjun,

The crank error flags are accumulated (bitwise-ORed) in the crank eTPU software and then cleared every time the fs_etpu_crank_get_states() API is called. Thus the two values you mentioned work out to several accumulated errors: 108 => 64 (TIMEOUT_AFTER_GAP) + 32 (TIMEOUT_BEFORE_GAP) + 8 (STALL) + 4 (TIMEOUT)  and  -116 => 140 (unsigned int8) => 128 (TOOTH_IN_GAP) + 8 (STALL) + 4 (TIMEOUT).

I have not looked at your crank signal data nor tried to simulate it, but I would assume it is such that it results in a cascade of errors that net error values of 108 and 140.

John Diener
802 Views
arjunraveendran
Contributor III

Hello John,

 

Thanks a lot for the answer. it makes perfect sense.

Could you also suggest at what rate fs_etpu_crank_get_states() function needs to be called? is the crank ISR at every engine cycle sufficient?

 

Thanks,

Arjun.

0 Kudos
798 Views
johndiener
Contributor IV

For most of the data retrieved by fs_etpu_crank_get_states() once per cycle is probably sufficient (and note that the ISR also fires on stall detection or during syncing when the host needs to evaluate cam data for full sync). But for (instantaneous) speed and perhaps other parameters, polling at a higher rate (10ms or faster) may make sense depending upon your application. A new interface that only retrieves the necessary data for these needs may be better than re-using fs_etpu_crank_get_states().

John Diener
688 Views
arjunraveendran
Contributor III

Thanks for the inputs.

0 Kudos