MY2020 VR30DDTT (Gen 2) ECU differences
In late 2019, early 2020, Nissan/Infinity released a new ECU type for all VR30DDTT powered vehicle’s which included a new processor type and architecture, but very little changes to the engine design or hardware. The only hardware changes known to EcuTek are the loss of the EGT (which predates the new ECU regardless) and removal of some of the spare inputs (pin 60).
The calibration data and control strategies are very similar to the old ECU type, and RaceROM features have been designed as close as possible to the existing functionality.
The known differences are:
The introduction of the P061B and other monitoring functions (see Monitoring subcategory for new maps).
Additional basic torque calculation maps (which shouldn’t need tuning)
inclusion of unrelated Renault based strategies.
As the new ECU has some hardware changes internally the following features cannot be used:
EGT Sensor Inputs.
Pin 60 Sensor Inputs.
Voltage inputs over sensor Pins
There is also a change to the way the map definitions are used in the software as well, so map naming while the same, is now easier to update and adjust user levels etc.
Support Note
If when using the product you find that certain features don’t work or there are issues that normal tuning does not solve, simply contact support@ecutek.com and please make sure to attach as much information as possible regarding the issue to the email so the support team can quickly and easily work to find the issue and solve the problem.
If you have an unsupported ROM please submit the new ROM via the normal ROM dump category and the ROM adding team can get onto the Addition as soon as possible.
Flex Fuel and Sensor inputs (via CAN)
Due to the loss of the extra input hardware on the ECM, you can only use CAN Inputs, to get a flex fuel sensor input over CAN you must use a CAN compatible ethanol content sensor kit. You will need to tee into the CAN wiring on the Main CAN bus, this bus is connected to many different modules and connectors all over the vehicle. there are a few possibilities for CAN wiring below.
Note: The OBD Port does not appear to be suitable for use with CAN Sensor imports as its possible that the gateway module prevents the communication from passing through onto the main engine CAN bus.
The ECM Pins or wiring
Pin 175 CAN Low
Pin 176 CAN Hi
Power Steering Control Module
To configure a flex fuel, fuel pressure or custom can device (for logging only at the moment) you will need to do the following
Configure a CAN Sensor Type to the sensor type in use, there are two CAN IDs available and you can select one of the Pre-set sensor types or a custom device.
You need to select the closest Expected Channel Frequency to the CAN devices send rate (which should be available from the kit manufacturer).
If using the standard CAN address you won't need to do any further configuration. If using a non-standard (User configured on the unit) CAN ID you'll need to change the values found under "CAN ID for ___" and add it in Hex format.
You will then need to set the sensor you are using up as an input. this is done by choosing the sensor and setting it as a CAN Input, If you are choosing a 0-5V input it may be used instead Sensors → Flex Fuel Sensor Source as CAN input
For Information on Custom CAN Sensors or other Preselected Units please see the RaceROM CAN Sensor Manual
If you are using 2 sensors at once, e.g. Ethanol Content and Fuel pressure you will have to manually set up a custom CAN device as per the link above. and then assign the CAN sensor output to a Channel Usage.
Note: You will need to set a channel multiplier of 0.01 for the ethanol content as the flex fuel calculation functions ONLY take a content value of 0-1 (not 0-100%). If you don’t scale ethanol content by 0.01 (to get a 0-1 value) the sensor will always be out of range and apply the torque limit. Ethanol content will read correctly from the flex fuel ethanol content logging parameter.
There is also the option to run pre mix blend maps using the Flex fuel code depending on the car owners preference and the tuners consideration.
Sensor Error Handling and Failsafe
Some CAN sensors or modules have the ability to report a failure codes using part of the can message (for senor disconnect / voltage out of range etc). This can be done by sending a byte in the can message (e.g. the ECA-2 error state byte) that contains bit flags for an error condition. You can choose which of these bits you which to ignore or allow to set an error state in the can sensor function using the CAN Input Failure Error Mask. these are set as for default as FF or interpret data as incorrect, so if the error byte has a value above 0 the sensor will be judged as in error state and use the last known good value and applying a torque limit.
When no information is received or the Information is determined to not be reliable by looking at send and receive message rates the CAN sensor functions will start counting the lost frames (at the receive frequency). Once it goes above the Frame Lost threshold be put into a failsafe mode.
The CAN sensor Timeout allows a failsafe to be triggered in the event that no signal is reported from the sensor within the chosen time frame. (milliseconds)
In the failsafe mode a Torque limit will be applied, and the Sensor system uses the last know good value of the sensor reading.
Note - The ECA-2 sends messages at 4Hz and the current implementation of frequency measurement only has a number of set frequencies, the lowest being 10HZ, so you will always see a number of missed messages in the count. There are a few options to get around this issue,
You can set the error threshold high enough so that even with the difference in refresh rate it doesn't set off the can error function. (this is believed to be around 50 counts)
You can change the setting of the ECA-2 sensor to refresh at 10hz (sadly its not easy to change the code in the RaceROM patch to allow a CAN transmission check of 4hz or less at the moment).
You can the disable the expected frequency and run without send rate checking though the sensor error byte will still operate.
Boost Sensor 0-5V import
Currently this DOES NOT work as intended due to the nature of the way the boost control functions work so importing a voltage signal on one bank is not possible. You can however simply use this to disable one sensor and copy the value from one sensor to the other. (for now) the using the pinout for the boost sensor is below.
Once the sensor is wired into the ECU or the pressure sensor pins, you will need to make sure the correct bank boost sensor input is selected.
RaceROM Code will automatically copy one sensor value into the other banks to keep the ECU control happy. While this is not the most optimal solution until alternative methods of receiving inputs are created this is the only solution available with EcuTek.
P061B DTC’s
The introduction of the P061B and other monitoring functions (see Monitoring subcategory for new maps). There are many monitoring maps in different function and it is currently unclear what DTC’s will be triggered by which miss match in monitoring maps.
As there are monitoring maps but no direct link from them to the P061B DTC you will need to test and feedback which maps make a difference but there are some maps that look like they should match with torque demand, torque actual, and MBT timing etc so worth modifying these maps to match as closely as possible to the normal maps and see if you can get the P061B DTC under control.
The first of these maps is most likely the torque demand, sadly instead of a normal torque demand maps the torque demand monitoring function uses a 3D multiplier map and a 1D base value map.
to get the torque demand map and monitoring map to match closely enough you will have to profile the map to equal the as you normal torque demand map (easiest way is to scale by a percentage of 1/max torque demand value in your calibrated map, then copy this across in to the monitoring multiplier map) and then set the Max value to be the same as the max value in your normal torque demand map.
alternatively you can switch off the torque demand monitoring using the RPM thresholds.
ECU recovery
As with all EcuTek products, we have ECU recovery processes if programming events fail (e.g. battery voltage too low, EVI connection issue) these follow the same procedure as normal programming, however you may disconnect and reconnect the battery then manually select the correct programming window to proceed.
When using the Programming window after a failed programming event, the part programmed ECU message will be displayed, when this occurs you will need to select a completely stock ROM and recover the ECU. After this you can then program the tuned ROM back in.
It would be wise for tuners to supply Stock ROMs with tuned ROMs so that recovery can be completed without further delays when remote tuning (retail programming kits do NOT automatically get the VR30 stock ROM files).