NOTE: This post has been updated to reflect that the driver chips NOT related to injector control. Rather these chips are used for things like PWM outputs to the instrument panel.
One of the very early posts one this site shows a diagram of the firmware layout used on the Td5 NNN ECU's.
The portion of memory located between addresses 0x0000 - 0xFFFF was cryptically called "ECU Base Code", with the note that this is not touched during Nanocom .map uploads.
The "Base" code is possibly better described as management or boot loader code. In normal usage the main function it performs is basic setup of the ECU hardware, verifying that certain check points are present in the Variant and Fuel maps, then running the variant map code if everything correct.
The secondary function of the management code is to provide support for factory programming of the ECU. Without a variant or fuel map installed the ECU will boot into a special diagnostic mode that provides access to the functions need to upload .map files, program injector codes, synchronise with the BCU immobiliser, and set the throttle pedal type. I assume this mode would have been used on the production line to program new ECU after installation into a vehicle.
The management code is identical across all the NNN ECU's with two minor differences.
The first difference is the code identifier. Like engine maps each variant management has a unique identifier. The second difference is the ECU hardware code, which reflects the well know NNN numbering. So the thbtp001 ecu code has the indentifer NNN000120, whereas the thbtp005 has the identifier NNN500250.
The complete list is:
NNN000120: thbtp001
NNN000130: thbtp002
NNN500020: thbtp003
NNN500030: thbtp004
NNN500250: thbtp005
If you are simply uploading .map files using a diagnostic tool you don't need to worry about this as the management code is not touched even if you brick the ECU.
Where you can run into problems is if you upload a complete .bin file from a different ECU type.
One of the differences between the NNN000xxx and NNN500xxx ECU's is that the power driver chips used to control the injectors pwm output and some switches were changed from Intersil HIP0060 to Infineon TLE6220GP parts. While both types of chips use Serial Peripheral Interface bus to communicate with the MCU the format of the messages and the representation of faults differs.
The ECU code uses the identifier from the management code to determine which driver chip is present.
So if you fit a .bin from a NNN000120 to a NNN500020 or NNN500250 for example the Variant code will read the NNN000120 identifier and use the code for the HIP0060 driver chip, rather than the TLE6220GP.
What makes this problematic is that one chip arranges it's fault codes:
A_OverTemp, B_OverTemp, C_OverTemp, D_OverTemp, A_OpenLoad, B_OpenLoad, C_OpenLoad, D_OpenLoadwith a value of 1 signalling a fault.
The other uses:
A_bit1, A_bit2, B_bit1, B_bit2, C_bit1, C_bit2, D_bit1, B_bit2If both bit1 and bit2 are set to value of 1 the channel is operating normally, and if both are set to zero there is a "short to ground" fault present.
This means if you send the diagnostic bits from a HIP0600 showing no faults (all zeros) to an ECU configured for a TLE6220GP the best you can hope for is "short to ground" faults on all channels.
The injector fault checking is called in the main loop of the ECU code and it's potentially updated every 10 milliseconds or so.
I haven't been able to confirm how this impacts general running, but I've been speaking to someone who has had ongoing issues with poor starting who appears to be running NNN000120 management code on an NNN500250 so it seems fairly likely this is related.
Anyway, it's something to be aware of...