Hi,
I am currently studtying the AN4907 Engine Control demo. I am struggling the understand an operation about the resetting TCR2 value in the eTPU CRANK function.
Above image is taken from the CRANK_Stall_NoReturn(void) function in etpuc_crank.c file.
1. I know the reason why we should reset the TCR2 value, however I couldn't figure out the why we resetting the TCR2 value just if it is less than the 0x800000.
2. The comment above the if condition specifies that TCR2 value will be reset also in CRANK_SEEK state. However, after the stall condition, the state flow will not be continue with CRANK_SEEK, it will continue with the CRANK_FIRST_TRANS. Is it possible to be a mistake here or do I missing something?
3. Another thing is about the comment above the if condition, it specifies TCR2 as positive or negative. Is it possible to has negative value for TCR2? If yes, what is the negative values of TCR2 mean?
Best regards,
Mert.
At the time of a stall detection it is likely any fuel/direct injection/spark/knock channels have pending matches on future TCR2 values (but less than one engine cycle in the future, so not far in front of the current TCR2 value). So if the TCR2 value is in the negative half of its range, on set to 0 all such matches would immediately fire, as they would now be in the "past" according to the greater-equal match logic. Now, as you probably noticed, on stall links are issued to all instantiated fuel/direct injection/spark/knock channels, causing them to re-initialize. But this takes a little time, so there could be spurious output pulses if they had pending matches on values in the negative range. This is avoided by not doing the TCR2 reset when it is negative, BEFORE re-initialization.
On the flip side, why then is TCR2 set to 0 at the time of stall processing? When the next crank tooth is detected, TCR2 is again set to 0 anyways, so why also do it (conditionally) at the stall? The reason is because the global TCR2 engine cycle tracking variable is reset to (0 + 1 engine cycle tick count) to be in sync with the TCR2 counter:
/* reset TCR2 if it is positive, if it is negative it will be reset
in CRANK_SEEK (prevent from TCR2 jump ahead) */
if ((unsigned int24)tcr2 < 0x800000U) /* ensure that an unsigned comparison is performed */
{
tcr2 = 0;
}
eng_cycle_tcr2_start = eng_cycle_tcr2_ticks;
The reason it is initialized to eng_cycle_tcr2_ticks rather than 0 is that during pattern synchronization the TCR2 will count in the region of [0, eng_cycle_tcr2_ticks) and potentially get reset back to 0 as the pattern is found. None of the dependent channels want to match during this process so their starts are offset into the first full synchronized engine cycle where TCR2 ranges in [eng_cycle_tcr2_ticks, 2*eng_cycle_tcr2_ticks). If at stall the TRC2 value was positive (e.g. 0x234567) and left as-is instead of reset to 0, when the fuel/direct injection/spark/knock channels re-initialized immediate matches would result, causing big problems.
With regards to question 2, since the synchronization process already went through the SEEK and BLANK_TEETH states previously, and a quick re-synch is desirable, stall resets to FIRST_TRANS rather than SEEK. Anyways, this is my interpretation of why the code is the way it is.
#3. In this engine code all matches are configured in greater-equal-mode. Thus "future" relative to TCR2 is the range [TCR2+1, TCR2+0x800000], and "past" is [TCR2-0x7fffff, TCR2]. Thus when TCR2 is exactly 0, then negative values represent the "past", and positive represent the "future". Some info from a reference manual:
At the time of a stall detection it is likely any fuel/direct injection/spark/knock channels have pending matches on future TCR2 values (but less than one engine cycle in the future, so not far in front of the current TCR2 value). So if the TCR2 value is in the negative half of its range, on set to 0 all such matches would immediately fire, as they would now be in the "past" according to the greater-equal match logic. Now, as you probably noticed, on stall links are issued to all instantiated fuel/direct injection/spark/knock channels, causing them to re-initialize. But this takes a little time, so there could be spurious output pulses if they had pending matches on values in the negative range. This is avoided by not doing the TCR2 reset when it is negative, BEFORE re-initialization.
On the flip side, why then is TCR2 set to 0 at the time of stall processing? When the next crank tooth is detected, TCR2 is again set to 0 anyways, so why also do it (conditionally) at the stall? The reason is because the global TCR2 engine cycle tracking variable is reset to (0 + 1 engine cycle tick count) to be in sync with the TCR2 counter:
/* reset TCR2 if it is positive, if it is negative it will be reset
in CRANK_SEEK (prevent from TCR2 jump ahead) */
if ((unsigned int24)tcr2 < 0x800000U) /* ensure that an unsigned comparison is performed */
{
tcr2 = 0;
}
eng_cycle_tcr2_start = eng_cycle_tcr2_ticks;
The reason it is initialized to eng_cycle_tcr2_ticks rather than 0 is that during pattern synchronization the TCR2 will count in the region of [0, eng_cycle_tcr2_ticks) and potentially get reset back to 0 as the pattern is found. None of the dependent channels want to match during this process so their starts are offset into the first full synchronized engine cycle where TCR2 ranges in [eng_cycle_tcr2_ticks, 2*eng_cycle_tcr2_ticks). If at stall the TRC2 value was positive (e.g. 0x234567) and left as-is instead of reset to 0, when the fuel/direct injection/spark/knock channels re-initialized immediate matches would result, causing big problems.
With regards to question 2, since the synchronization process already went through the SEEK and BLANK_TEETH states previously, and a quick re-synch is desirable, stall resets to FIRST_TRANS rather than SEEK. Anyways, this is my interpretation of why the code is the way it is.
#3. In this engine code all matches are configured in greater-equal-mode. Thus "future" relative to TCR2 is the range [TCR2+1, TCR2+0x800000], and "past" is [TCR2-0x7fffff, TCR2]. Thus when TCR2 is exactly 0, then negative values represent the "past", and positive represent the "future". Some info from a reference manual:
