When I was conducting engine tests, I encountered an eTPU crankshaft tooth counting error that caused the engine to no longer synchronize.
When I check "*cpba_tooth_period_log" in “crank_instance_t",I foung some member become very small。
The experimental results are as follows.While running, etpu_tooth_period_log[80] suddenly drops from 33800 to 21800.And crank states err occur.The rest of the etpu tooth period log(log[0],log[40],log[119],) data looks normal.
I checked the input crankshaft original signal and there was no signal anomaly when the fault occurred.I tested the duration of the first 1 and 2 teeth of the failure,They all last around 820us.
Here are some of my eTPU parameter matching values.
I also added an IO flag to the crankshaft interrupt function, which outputs the current state of the IO output after entering the interrupt.In the figure below, the blue signal is a sign that the entry crankshaft is interrupted.
Green indicates synchronization. When the green signal is high power level, it indicates non-synchronization("crank_states.eng_pos_state" is not "FS_ETPU_ENG_POS_FULL_SYNC").
As can be seen from the diagram, the crankshaft abnormal entry break caused the engine to no longer synchronize.
Could you help me analyze the cause of this problem and how to solve it?
Thank you very much!
You have solved my problem, thank you very much.
However, I still have other puzzles in the use of eTPU. I have created a new topic as follows....
Hi Jasting,
excellent observation! Thanks for pointing this out. I've created a similar setup, located the issue (after few minutes of execution) and ... fixed a bug in INJ.
You can take the attached file and update the "_etpu_set" folder in the example application, or you can create a new eTPU function set yourself using CW eTPU Function Selector - the fix is already available there.
Regards,
Milan
Thanks for your reply!
I have connected ETPUA1 to ETPUA2 and ETPUA3 to ETPUA4.Have been collected to ETPUA10, ETPUA11 ETPUA12, ETPUA13 injection signal.
I made some simple adjustments to the routine you gave me.I have added monitoring for injection status errors to each injection interrupt, with the "LED2_pin" output low when a fault occurs.All four channels are set this way.The state of this pin is externally observed through an oscilloscope.This pin is observed to be low after some time, indicating that an injection state failure has been detected.This is consistent with my previous tests.
As shown in the figure below, I monitored the status signal for injection status errors (blue) and the signal for injection channel One (yellow). When the injection status error signal appears, there is a problem of injection signal loss. (Not every injection error is accompanied by injection signal loss, but every injection signal loss is accompanied by injection error)
Hi Jasting,
we created an example project for you. It includes eTPU code newly generated by CW Function Selector. It uses TG function to generate a CRANK & CAM pattern. In order to feed the CRANK and CAM inputs by TG outputs, connect eTPU A channel 1 and 2 (CRANK), and 3 and 4 (CAM). INJ outputs are on eTPU A channels 10, 11, 12, 13. INJ configuration mimics your case.
Could you provide a eTPU2 test project that can work normally, so that I can test and troubleshoot problems?
Yes, I've changed all of its configuration areas to 100.
Did you change the injection parameters? Injection duration must not be 0.
Whether or not the injector is connected, "inj_states_t.error" will periodically report the "FS_ETPU_INJ_ERROR_LATE_START_ANGLE_NTH" fault, and the frequency of the fault is related to the engine speed. The faster the speed, the faster the frequency.
The following is the injector drive diagram.There is no associated pin to change the state.
I don't my yesterady's replay here in the chain. Hm, let me write it again.
Thank you for the information.
In addition, in my previous tests, the failure did not occur when the injector was not connected. But I'm not sure it's necessarily related.
Thank you for the information. The first observation is the behaviour of the INJ function. The duration of each injection pulse is set to 0. According to the detailed scope, the first injection pulse is about 400 usec and the second about 800 usec. Duration of 0 is nonsence. It might cause a wrong order of events or something like that. Please try to set e.g. 100 usec duration of each injection.
Next observation on the same detailed scope is that the injection duration of 800 usec corresponds to 1 tooth period. If there is a latency as long as one tooth on the eTPU engine, that would break the tooth processing and cause the synchronisation lost. I'm not sure where the latency might come from. Each event (transition or edge) should be processed within 2-5 usec. Anyway, the duration of injection pulse, set to 0 but generated as 800 usec, shows there might be such a latency.
Please monitor INJ error variable:
struct inj_states_t
{
uint8_t error; /**< This is the error status of INJ. It includes
the following error flags:
- @ref FS_ETPU_INJ_ERROR_PREV_INJ_NOT_FINISHED
- @ref FS_ETPU_INJ_ERROR_LATE_START_ANGLE_1ST
- @ref FS_ETPU_INJ_ERROR_LATE_START_ANGLE_NTH
- @ref FS_ETPU_INJ_ERROR_STOPPED_BY_STOP_ANGLE
The eTPU sets the error flags, the CPU clears them after reading. */
Generally, it is very difficult to find a bug which appears once per hours or days. You can try to narrow the reason by removing the INJ at all, and if the issue disappears, try to add injections little by little.
Another technique is to use FreeMASTER. It enables set a trigger on the sync loss and record selected eTPU variables, including pre-trigger values.
The best options would be to use Lauterbach with trace and record all the processor and eTPU behaviour before the sync lost.
In summary:
- set injection durations to 100usec
- monitor INJ error
- remove INJ
(- prepare FreeMASTER)
Milan
Thank you for your reply.
1)On the eTPU Engine,I use three functions(etpu_crank,etpu_cam and etpu_inj),and their are the parameters as follow.
2)I marked the signal on the scope .
yellow signal - Fuel injector operating current,As is shown in the picture, there is a loss of signal at ①.
magenta - crank signal.
blue - eTPU crank isr flag.This flag flips when the entry eTPU crank isr.
green - when crank_states.eng_pos_state" is not "FS_ETPU_ENG_POS_FULL_SYNC",it become high.
3)Yes ,of course.Is the information I provided above about the tooth period log inadequate?
if so i will do this.But it may take some time.
4)The loss of synchronization happens at different positions and occasionally.Sometimes every few minutes, sometimes every few hours, sometimes every few days.
Hello Jiandong,
could you give me more detailed information?
1) What are all the functions running on the same eTPU engine, their parameters, timing, ....
2) What are the signals on the last scope
yellow signal - ???
magenta - crank
blue - toggle is an interrupt? which interrupt?
green - crank_states.eng_pos_state" is not "FS_ETPU_ENG_POS_FULL_SYNC"
3) If possible, can you make a memory dump of eTPU DATA RAM, starting at Crank cpba, including the tooth period log?
4) Does the loss of synchronization happens always at the same position, at different positions, or just occasionally?
Regards,
Milan