Ok, it's time to reveal nature of the VVE Bug.
Gen4 ECM uses VE for calculation of the 4 things:
- SD airmass (Actual MAP)
- maximum reachable airmass (Max Reachable MAP = BARO + MaxPossibleBoost)
- Diag MAP Model 1 (estimation of MAP to match Engine Airflow and Throttle Airflow)
- Diag MAP Model 2 (estimation of MAP to match Engine Airflow and MAF Sensor)
All 4 VE calculations uses different MAPs and current engine speed.
Those calculations is grouped and executed in different tasks. Yes, ECM and TCM utilizes multitasking OSes.
SD Airmass and MaxReachable Airmass is calculated in one group in the cylinder event task (once per cylinder event).
Diag MAP Models is calculated in another group in one of the the periodical tasks (80 Hz or every 12.5ms).
Due to complete asynchrony of those tasks it a matter of time that tasks have to be executed simultaneously (i.e. to interrupt one another) and this is absolutely normal in the multitasking environment if the code is well organized and special care taken for critical sections. But as you can already anticipate it is not.
VVE calculation routine at first collects all VE terms from the tables using current IMTV position and DoD mode and then do math. All VE terms except one are stored in processor registers, but MAP^2 term is stored in a global memory variable. When the "lucky" chance comes cylinder event task is interrupted at right moment when MAP^2 term is stored and 80Hz peridocal task executes its own VE calculation then this variable contains MAP^2 term from the Dynamic Airflow Zone corresponding to Diag MAP Model 2 which may be different, but most of the time they are the same.
When we are disconnecting MAF it shows zero flow and MAP Model 2 drops to the minimum allowed value ([ECM] 34972 - MAP Estimated Min: Estimated minimum MAP value) which is 10 kPa in order to achieve zero Engine Airflow. This gradually rises the chance for VVE spike because now Zone for Actual MAP and Zone for MAP Model 2 can be equal only on the coast.
If we get back to Cringer's most indicative log
It is now very easy to reproduce VVE spike calculation.
Log just before spike
1 log pre.png
Correct VE, Actual MAP/RPM in Zone 7
2 ve pre.png
And now the spike
3 log spike.png
Corrupted VE with a MAP^2 term in Zone 7 taken from Zone 6
4 ve spike.png
As you can see calculated and logged VEs are very close.
What can be done to get rid of the spikes?
1. Patch OS so that MAP^2 term will be stored in a stack variable (which will be unique for each task) and not in the global memory. It requires modification of only 4 instructions of the VVE calculation routine.
2. Completely zero out [ECM] 13410 MAP^2 table so that even when VVE Bug fires MAP^2 term remains the same (zero). In this case VE will look much worse and will loose smoothness but this is still a working solution. This will require creation of the special tool to convert VE. Simple zeroing-out of the [ECM] 13410 table will corrupt VE.
It is known for sure that all E38 and E67 OSes are affected. E37 is very likely affected too but that have to be confirmed.
Originally Posted by GHuggins
Maybe I should have worded differently instead of grouping everything together. Will the rpm settings be available via xdf and do they just need to be the same as the dyn settings? Added the last part but it just came up as another possible question
Reply With Quote
