Welcome to DiscoTd5.com, a site dedicated to the Land Rover Td5 Engine. The DiscoTd5.com website springs from the interests and experiences of my ownership of a Td5 Discovery which I purchased in May 2011. Since I first set up the site, my interests have become heavily focused on reverse engineering the Td5 ECU firmware, and I'd expect this focus to remain for the foreseeable future.
I've been working on a disassembly of a K-Series engine map that runs on an NNN petrol MEMS ECU for last day or so.
While there is a basic level of commonality with the Td5 this is very much restricted to low level drivers and some utility functions, like map lookup and interpolation, basic kline drivers, CANBUS drivers, etc, etc.
It's this type of functionality that accounts for the similar appearance of the ECU fuel maps. The lookup for sensor scaling is pretty much identical, even though the actual processing has significant differences, for example.
Once you move beyond this "housekeeping" code, you are firmly into the realm of engine specifics.
So yes, MEMS are similar up to a point - but this also hides a lot of difference in the actual engine code.
In other words "MEMS ain't MEMS"
While things have been fairly quiet on the site recently, that hasn't really been a reflection of the level of work that has been going on at the DiscoTd5 Lab for last three or four months...
The datalogger had pretty much been dumped in parts bin as the level of work required to get it up to a useful state seemed to be overwhelming. Conversation with an enthusiastic D2 tuner convinced me to take another look - on the basis of build it or bin it for good.
Three months later, and hundreds of hours rewriting the code, it's slowly starting to come together.
The biggest chunk of effort - which has basically eaten the last 4 weeks - has gone into writing a SDCard // FAT32 library from the ground up. This was the obstacle that had resulted in the project being shelved previously so it's been a significant hurdle to overcome. There is still work to do but there is now light at the end of the tunnel.
It might seem a bit bizarre to be writing a FAT32 library from scratch when there are well established products like the ELM Chan FATFs available.
The main issue has been that the logger code is written in a way that requires components to be non-blocking. Blocking code will prevent any other code running while the blocking waits in a loop for something to happen - it literally blocks progress.
ELM Chan's FATFs is blocking in that it waits for SDCards to come out of busy state before proceeding. The issue here is that at times cards can be busy for extended periods - 50ms is not unusual even with a good quality card like a SanDisk Ultra. With poor quality cards wait times of 200ms+ are not uncommon.
Where this becomes a problem for a Td5 data logger is that the default time between an ECU response and the next "tester" request is 25ms.
The Nanocom Evo solves the problem by making a series of requests - one log line of data - then writing that line to file. There is a 600ms+ pause between the end of one block of data, and the start of the next which is plenty of time for even the slowest junk SDCard to finish writing and return to idle state. But this also means that the Nanocom is writing one line of log data every 1.25 seconds. Fine for some purposes but a lot of dynamic behavior "falls through the cracks" - the torque reduction of an auto shift completes in under 300ms for example, so is effectively invisible.
The approach I'm taking here is to use non-blocking code with DMA (direct memory access) transfers of data to the card. The DMA transfers effectively run in the background without processor intervention, so the combination means that the processor only needs to setup the write to the SDCard, and then can resume more important tasks like reading data from the ECU, or other sensors. The issue of wait times is dealt with by buffering the data waiting to be written to card. In theory all this will allow data rates 10-15 times faster than the Nanocom to be written to card without delays caused by slow card writes.
An excuse for new toys
One of the issues I'd have was that my old Saleae Logic - an original and now much cloned 8 channel 24Mhz job - is starting to show it's limitations when trying to capture communication with the SDCard at 20Mhz bus speed. To capture a signal you need at least twice the frequency of the signal - so 40Mhz at least - ideally you oversample at x4 so 80Mhz. With the old Logic I was flying blind.
As much as I love the Saleae and the software, a new Logic 8 Pro which has sufficient speed for this task was prohibitively expensive - 700-800USD.
So I've ended up with an open source design analyser that does either buffered or streaming captures. The buffered captures are made to internal memory, and have fairly limited length of capture. around 1 second @100MHz using 4 channels, and 300ms @ 400Mhz using 4 channels. Streaming captures are sent over usb to an open source, cross platform application based on Sigrok. The buffered captures are limited to 100Mhz with 3 channels, or 50MHz when using 6 channels. For the SDCard work I need 4 channels and long captures so need to use the 50MHz/6 Channel option. So not perfect but it's flexible enough to be quite useful. Best thing was that it's far more affordable at $150USD.
The Logic is the small black square on the left, the DSLogic Plus on the right is significantly bigger but still fairly compact.
And the DSLogic proved it's worth within an 30 minutes of unboxing.
I'd had an issue where the code would run perfectly with the Saleae connected but would then fail as soon as I disconnected.
It's a real catch22 - the bug occurs only when your debugging gear isn't connected... makes troubleshooting fun. The DSLogic has coaxial probe leads which significantly reduce the effect on the signal being monitored compared with the Saleae's flying leads. There is a great comparison of a Saleae clone and DSLogic on the OpenTechLab channel on YouTube - the sims of the effect of flying leads is quite an eye opener.
The video above mentions the probe clip quality. The ones that came with mine seem to be cheap knock-offs of ez-hooks. Not quite as clunky as those seen in the video, but hook wire is pretty flimsy compared with ez-hooks.
The upshot was that even with the DSLogic connected the "undebugable" bug was occurring every time a card was inserted, and it was straight forward to isolate where and why the code was failing.
The software is fairly good but a bit rough around the edges at least under macOS. I have a bit of trouble with zooming using the trackpad - it's clearly designed for left and right buttons plus scroll wheel. Protocol decoding seems accurate but is slow compared with the Saleae app, although to be fair10 second captures at 20Mhz were regularly bringing that program to the point where a force quit was required, and in one instance a full reboot.
For the money it is pretty decent, and the cross platform software is a big plus in my book.
Worth noting that the DSLogics sold on eBay are not covered by a manufacturers warranty.
I opted to purchase direct.
Check your spam folder...
It appears that a couple of webmail services - hotmail.com in particular - are quietly filtering emails from the discotd5.com domain to spam.
Donors will always get a "Thank you for your donation email" from the site within a few minutes of the donation being made, and I try to get donor accounts setup same day, but it can take up to 2-3 days if I'm away, and have limited internet access.
When the account is created an email advise the account has been setup is sent. This contains a one-time login link.
If you have donated and didn't get a "Thank you email", first thing is to check your spam folder.
If 3+ days have passed, and you haven't got an account creation email, first thing to do is check your spam folder.
In particular if you have used a Hotmail account to donate - just check your spam folder for email from @discotd5.com.
I've had a few requests for details on how to disable the timeout on EU3 maps when the MAF sensor is disconnected.
Without this mod the throttle on EU3 maps is unresponsive for 20-30 seconds when the engine is first started.
It's quite simple to do by altering the MAF "out of range" timeout check from a conditional "if timeout branch" to an unconditional "branch".
You'll need to use a HEX editor for this.
First open up you .map file in your favorite hex editor - I use Hex Fiend on macOS for stuff like this.
With the .map open search for a sequence of hex bytes: 66 30 31
There should be only one occurrence of this sequence in the .map file at an offset of somewhere around 0xD100 - 0xD400.
Next, change the 66 to 60 - this alters the conditional branch instruction to an unconditional branch, meaning the ECU always executes the "no MAF" code.
Save the modified .map file and you are done.
Be aware that this mod “lobotomizes" the EU3 maps to a EU2 style single smoke map configuration.
The ECU will only use the main high range smoke map (map 60).
This should work for all EU3 variants.
If you can't locate the byte sequence let me know which variant you are working with.
Note: The checksum needs to be updated if you are loading the .map using the Nanocom. This can be done by loading the .map file into Tuner Pro with the appropriate XDF and then saving the "bin". The checksum is updated on save. Td5 Map Editor will also update the checksum. If you are using Td5 ME you'll have to either make and the reverse a change to the map so the file is marked as "dirty" then save, or "save as". Thanks to Neil for mentioning this omission.
Is Front Left the new Right Rear?
Getting id of sensor values correct is just so last season...
I've had the 4 amigo's hanging about for a while and finally decided I better fit the replacement sensor that has been kicking around for the last month or two this morning.
Fault codes have been showing an intermittent fault in the right rear sensor.
Usual problem is knowing whether that is right facing the front of the vehicle or right facing the rear.
I'd been assuming right facing the front, but thought I'd double check before replacing.
Logical thing to do is pull the sensor connector and check the voltages with the Nanocom.
So I disconnect the sensor in the rear right wheel arch.
Then check the sensor voltages...
Cyprus, We have a problem..
Fortunately the fault codes are correct, and a quick drive revealed a rear right electrical failure.
I'm currently working on new method for generating XDF's which is providing a chance to streamline the process.
One issue that has been bothering me is that significant portion of the NNN XDF's are redundant. This occurs because the XDF's are currently created based on the variant-fuel map pairs in each .map file.
The reality is that the only difference between the fuel maps in for example swdxe007-swtnp004.map and swdxe007-swtnp006.map is the number of the variant map in the fuel map. The fuel map checksum also changes by the difference between the variant map version numbers.
Neither of these differences have any impact on how the XDF defines the tables and constants within the fuel .map. A small number of NNN EU2 maps have additional differences in 5-6 constant values but again the structure of the fuel map is the same, so one XDF definition can edit both versions.
So the upshot is that the next release of the XDF's will be based on the fuel map identifier only, and this will reduce the number of NNN XDF by about 30-40%.
XDF auto loading
Tuner Pro has the ability to auto load XDF's when a .bin / .map is loaded. Unfortunately this must be manually configured but it saves a bit of messing around once it's configured. It's usable with current versions of the XDFs but will make more sense when the XDFs are consolidated.
The auto loading is configured under Tools > Preferences > Default XDFs by selecting enable default definitions.
These are the offsets for the current NNN XDFs.
While it shouldn't be obvious, I've moved the website to a new host. The process has been fairly problem free but if anything is acting up let me know.
On a related topic Google Chrome and other browsers have started marking sites that aren't secured will SSL certificates as "not secure". It's really a bit of overkill for a site like this, but as the Not Secure warning is kind of off putting I've moved the site across to the secure protocol.
Chrome is currently still complaining because the images in a lot of the posts are hard coded to the insecure address. I'm slowing working my way through and fixing up the links.
For the moment the front page and the donor login pages are now flagged as "Secure".
We tend to assume that when you plug in a specialist fault code reader the codes that are reported are correct.
Unfortunately that faith seems to be misplaced.
Initially I thought this was a problem that only afflicted the Nanocom but a recent posting on a UK forum suggests that the Hawkeye suffers from the same problem.
The codes that had been posted will be familiar if anyone who as tried running an EU3 map on an EU2 vehicle.
- (4,3) Coolant temperature circuit. (Logged High).
- (6,3) Coolant temperature circuit. (Current).
- (24,7) Problems detected with auto gearbox. (Current).
- Fault 3018 Coolant temperature High Fault logged
- Fault 3034 Coolant temperature Fault Active
- Fault 3174 Fault detected with automatic gearbox
The three "phantom" faults reported are caused by the lack of Ambient Air Temp sensor which is part of the 4 wire AAP/AAT sensor used on the EU3 engines. And the codes can be eliminated by adding an extra wire and the EU3 airbox lid and sensor.
But that doesn't explain why the fault codes do not reflect the actual fault.
We investigate anomalies...
It's not widely known that the EU2 NNN maps include code to process the output of the Ambient Air Temp sensor, although the data is not used by the engine maps. I currently have an EU3 4 wire AAP/AAT sensor fitted but have gone back to running EU2 maps. With this setup I discovered the AAT readings are returned as part of the live data. Unfortunately the AAT sensor is completely ignored by the Nanocom, despite multiple requests that this be added.
Given that both EU2 and EU3 NNN maps are AAT aware, it would be fairly surprising if the ECU code was setting incorrect fault bits.
Looking at the ECU code for EU2 and EU3 NNN maps shows that the bits which correspond to faults 4-3, 6-3 and 24-7 are set by code that handles the AAT sensor. So these faults should actually be shown as AAT faults - logged high, active fault, and voltage out of range.
Let's go back, way back...
So at this point I started looking back at the MSB code....
Fault 4-3 corresponds with ECT sensor over voltage, check.
Fault 6-3 corresponds with ECT sensor active fault, check.
Fault 24,7 corresponds with Auto fault, check.
In other words the fault codes are correct on MSB ECU's, but wildly incorrect on NNN ECU's.
Unfortunately this issue doesn't effect just the AAT sensor.
There was some internal reordering of ADC inputs done in the upgrade from MSB to NNN which means that 1 in 4 of the fault codes in the 1,x - 6,x range are incorrect. An additional fault in that range cannot be correctly identified without a code that is "invalid" for the MSB and therefore not reported by diagnostic tools.
Beyond the basic input checking codes (1,x - 6,x) there are additional errors and major omissions.
Checking out some of the faulty codes on forums I've seen at least one instance where someone was told to replace the throttle position sensor when the fault code actually related to the MAP sensor... It wasn't surprising to see that after forking out a few hundred for a new pedal the person reported back that the new pedal had not solved his problems.
Other problems with incorrect codes are deemed as "quirks" when it becomes obvious the "faulty" part is fine and advice descends rapidly into random part swapping recommendations.
You just have to wonder how much money has been wasted based on the these incorrect codes...
So if you own a vehicle with an MSB ECU count yourself lucky - any fault codes will be correct.
NNN owners will just have to console themselves with the fact that the codes will be correct about 75% of the time...
The Nanocom .map and .tun formats is pretty much a standard for distributing remaps and loading different stock maps.
It should be fairly obvious that this was not just accidental. The support for Nanocom ID and VIN locked files plus respecting the NO READ attribute which prevents tunes being read back out of an ECU are clearly aimed at establishing the Nanocom as an acceptable remap delivery tool.
And this probably the key weakness of the Nanocom as a programmer - it is designed for uploading completed tunes to a customers vehicle.
This has become glaringly obvious over the past week when I've been trying to test mods to the Wastegate Modulator control maps. The testing requires repeated increment and test cycles, and this is where the Nanocom shows just how unsuited it is to the task.
As many are aware the ECU uses a variant map and fuel map pair. The variant is basically the program code and the fuel map is the configuration data. The variant code is only very, very rarely modified, and in most cases only the fuel map is touched. The XDF's only modify the fuel map.
The variant map is approximately 100Kb and the fuel map is 16Kb. The Nanocom erases and programs both maps each and every time it does a .map upload. That little bit at the end of the upload that takes 10-20 seconds to complete is the fuel map being programmed.
Each time you program with the Nanocom it goes something like this..
- Copy tune to SDCard
- Place SDCard in Nanocom
- Connect Nanocom to OBD port
- Wait for Nanocom to boot
- Navigate to Td5 Map module
- Select .map
- Wait for Nanocom to verify checksum and "protection"
- Turn on ignition, then push button on Nanocom
- Turn ignition off, then push button on Nanocom
- Wait 15 seconds
- Turn ignition on, then push button on Nanocom
- Wait while Nanocom erases then programs variant and fuel maps ( approximately 2 minutes)
- Cycle ignition
If all goes well - and it often doesn't - that process takes at least 4 - 5 minutes.
And yesterday when I was trying to upload a small mod and the Nanocom repeatedly failed at the "protection" check I decided that it was time to bite the bullet.
Enter the BDM
I've had a USBBDM interface for a few years, primarily to recover ECU's bricked by failed Nanocom uploads, but I've been conscious of the fact that tools like WinOLS offer BDM programming interfaces for remapping. BDM is typically used in bench programming setups, however I've added a 10-pin header to my ECU to make debricking a bit more straight forward.
So the simple solution was to connect a short ribbon cable with IDC sockets to the BDM port on the ECU and then feed the cable out under the edge of the lid. It's not perfect as the cable can be damaged by the lid, so I'll probably file a shallow notch in the case so there is less pressure on the wires.
The setup works reasonably well as the BDM port is near the upper edge of the case when installed in a D2.
Ideally I need a longer USB cable so I can reprogram from the drivers seat with bonnet down but this was basically a quick test to see how practical the idea was, so I popped the bonnet to do the reprogramming.
And the result was: very practical
There is currently a little to much "are you really sure" checking in the recovery scripts which makes things a little slower than necessary. Once you have the USBBDM interface hooked up it's pretty quick. It takes less than a minute to select and program a new fuel map. The actual programming is done in a couple of seconds and there is no worry about the upload freezing.
A month later...
I first started writing this post about a month ago, and I haven't even considered using the Nanocom to upload a tune since then. The main fiddle at the moment is popping the bonnet to plug in the USBBDM but even with this the fact that you know the tune will program first time makes it a winner. Normally I wouldn't load a map if I was away from home, but loading using BDM is so reliable I don't even hesitate to make adjustments and upload the modded map.
Information about the script package can be found in this post. I've made a "remap" version of the recovery scripts that prompts for a .bin fuel map as soon as it runs and only asks once if you want to program.
Working with fuel maps
There are a few minor changes that need to be made to adapt the XDF's for use with fuel map .bins. I'd recommend making a copy of the original.
Open up the XDF header information. You'll see something that looks like this.
Change the Bin Size (Hex) to 3FFF and the Base Offset (Hex) to 0, then click apply.
Click the checksums tab, and delete the map checksum. That is Nanocom specific and not required.