Intermittent start up problem
Discussion
That's interesting to hear, and may well be my next area to look at if the new NVRAM doesn't solve it. Did you find out what caused the damage, and where on the engine loom it was? I've seen lots of instances where the wiring should be better protected from rubbing on bodywork, getting too hot etc etc.
non_linear said:
All I need now is a small child I can send down the footwell to change it for me. I'm pretty certain I can't get down there without taking the steering wheel off and removing the drivers seat.
It's not happened often enough for me to correlate it with ambient temperature. I'll report back what difference it makes when the chip is installed.
I didn't know there was a separate speed six forum! I'll check it out.
You can just about withdraw the ecu but you need to take off the pedal cover and be a contortionistIt's not happened often enough for me to correlate it with ambient temperature. I'll report back what difference it makes when the chip is installed.
I didn't know there was a separate speed six forum! I'll check it out.
Btw after many years of fettling my car no longer does anything weird after start up but it used to. I do have a new Dallas but also have a new throttle pot. Dallas didn't make any diff...did it as a precaution
Yep difficult to see how the dallas could affect the start up, but i'm not discounting it .. I've learned that sometimes unusual things happen that you weren't expecting.
However for the dallas to affect start up 1, but be corrected for start up 2 doesn't make sense. What that implies is that the dallas data is corrupted for start 1, but magically corrects itself for start 2 .. not really sure how that can occur, but willing to proved wrong!
On the subject of rougher driving when cold :
that could be down to the way the ecu is set to prop up the idle speed on cold starts.
You have two coolant temp based ignition advance trimming tables for cold running, one comes into play at idle and very small throttle openings and is designed to help prop up the idle speed to prevent stalling on closed throttle. The second is the trimming table which comes into play at all larger-than-that throttle openings.
The thing is that at very low temps the idle compensation map has significantly more advance in than the larger throttle compensation map, so as your foot presses the throttle and the throttle values pass the idle threshold table value onto the second table there is a marked reduction in ignition trimming going on, and you can feel that as a noticeable reduction in both power output and smoothness.
However for the dallas to affect start up 1, but be corrected for start up 2 doesn't make sense. What that implies is that the dallas data is corrupted for start 1, but magically corrects itself for start 2 .. not really sure how that can occur, but willing to proved wrong!
On the subject of rougher driving when cold :
that could be down to the way the ecu is set to prop up the idle speed on cold starts.
You have two coolant temp based ignition advance trimming tables for cold running, one comes into play at idle and very small throttle openings and is designed to help prop up the idle speed to prevent stalling on closed throttle. The second is the trimming table which comes into play at all larger-than-that throttle openings.
The thing is that at very low temps the idle compensation map has significantly more advance in than the larger throttle compensation map, so as your foot presses the throttle and the throttle values pass the idle threshold table value onto the second table there is a marked reduction in ignition trimming going on, and you can feel that as a noticeable reduction in both power output and smoothness.
Edited by spitfire4v8 on Sunday 31st October 11:38
Personally I find it completely plausible. A low lithium battery could mean corrupted values are written into the NVRAM. It's possible that values outside of an expected range cause the program to behave unpredictably. Take a random number generator as an example, generating numbers between 0 and 100. If the code expects values between 0 and say 90 then most of the time it's fine, 10% of the time it will crash. Run the generator again (cycle the power) and there is a 90% chance the code runs fine.
In the ideal world you check for values being in range, and decide what to do if they aren't but a lot of programmers don't bother, or there are limitations on the amount of ROM available which means you don't have the space for the additional code.
I've written code in the past where you are trimming every last byte to get it to fit in the ROM.
In the ideal world you check for values being in range, and decide what to do if they aren't but a lot of programmers don't bother, or there are limitations on the amount of ROM available which means you don't have the space for the additional code.
I've written code in the past where you are trimming every last byte to get it to fit in the ROM.
Edited by non_linear on Sunday 31st October 13:07
That would maybe be easy to work out then ..
possibly look at the adaptive table immediately after a non-start and see if the data looks valid, then do the same immediately after a good start and compare the two. If the data is different the dallas info had been changed? if the info is the same then the dallas hadn't been changed?
possibly look at the adaptive table immediately after a non-start and see if the data looks valid, then do the same immediately after a good start and compare the two. If the data is different the dallas info had been changed? if the info is the same then the dallas hadn't been changed?
Edited by spitfire4v8 on Sunday 31st October 15:07
non_linear said:
That makes sense. If the battery has failed any data stored in the NVRAM will be corrupted. I've not tried reading the map but out of curiosity I might have a look.
I don't know how the MBE ECU was designed, but do know a bit 
about electronics. The Dallas DS1230Y chip provides battery backed data retention without external power for over 10 years. If the ECU provides power to the chip when the ignition is off (I don't know this part, but you would think it would be designed this way?), the chip will not lose data. Pretty sure this is why most TVR's with the MBE ECUs have not experienced any issues after well over 10 years of use. Obviously if the car battery has been disconnected for any length of time that could be a different story as that would run the internal chip battery down over time.Will be interested to see if replacing the chip solves the issue.
non_linear said:
That's interesting to hear, and may well be my next area to look at if the new NVRAM doesn't solve it. Did you find out what caused the damage, and where on the engine loom it was? I've seen lots of instances where the wiring should be better protected from rubbing on bodywork, getting too hot etc etc.
The harness looked ok, nothing visually obvious but breaking down when loaded (drawing current) the Ecu was rebooting itself (powering on and off) every 45 seconds at or near idle rpm probably on the first trim as Spitfire mentioned above, to cut a long story short it was due a 6k service so took it to my local dealer Str8six who swopped out the engine harness with one from their Tuscan2 race car to prove it was at fault and this instantly resolved the problem, a happy ending at last.Hopefully yours will be an easier fix, keep us posted on your findings, where there's a will there's usually a ..... relative
Englishman said:
If the ECU provides power to the chip when the ignition is off (I don't know this part, but you would think it would be designed this way?), the chip will not lose data. Pretty sure this is why most TVR's with the MBE ECUs have not experienced any issues after well over 10 years of use. Obviously if the car battery has been disconnected for any length of time that could be a different story as that would run the internal chip battery down over time.
I'd be very surprised if the ECU was powered when the ignition was off. The circuits show the ECU getting power through the immobiliser and that is consistent with how it behaves. MBETool only shows values when the ignition is on and the immobiliser cleared. The new part has arrived, but I seriously am not sure how I am going to change it!
Edited by non_linear on Wednesday 3rd November 10:45
Thanks for the encouragement! Agreed, not that hard. I put my old pot-holing headtorch on and crawled in.
So what have I found? It's early days, only a couple of runs so take everything I say as provisional.
The adaptives are now starting at 0.4 and making small changes immediately the engine fires. That is very different to what I was seeing before. Only time will tell if the bad starts have been banished, but I'm optimistic.
There are a couple of odd changes though:
The buttons on MBETool that allow the adaptives and throttle pots to be reset are now fuzzed out.
Once the Lambdas start switching I am seeing an AFR456 warning. That wasn't there before.
Any thoughts?
So what have I found? It's early days, only a couple of runs so take everything I say as provisional.
The adaptives are now starting at 0.4 and making small changes immediately the engine fires. That is very different to what I was seeing before. Only time will tell if the bad starts have been banished, but I'm optimistic.
There are a couple of odd changes though:
The buttons on MBETool that allow the adaptives and throttle pots to be reset are now fuzzed out.
Once the Lambdas start switching I am seeing an AFR456 warning. That wasn't there before.
Any thoughts?
This is one of those cases where the original tvr diags is superior .. you needed to look at the adaptive table to see the stored data.
The adaptives started at 0.4 because that is the default value when the adaptive table is blank... you would have seen the same thing had you reset the original adaptives in the dallas, as such this isn't a definitive test, and the fact you now have a fault showing is a worry obviously.
The adaptives started at 0.4 because that is the default value when the adaptive table is blank... you would have seen the same thing had you reset the original adaptives in the dallas, as such this isn't a definitive test, and the fact you now have a fault showing is a worry obviously.
The log shown is for the second run so wouldn't there be an adaptive table stored from the previous run? The previous run was about 20 min so long enough to get up to temperature.
Would you expect it to start with the last adaptive values stored when it was turned off?
Any idea why some of the buttons are now greyed out on MBETool?
Nothing has changed mechanically, so it seems odd that the MBE is now seeing an error.
Would you expect it to start with the last adaptive values stored when it was turned off?
Any idea why some of the buttons are now greyed out on MBETool?
Nothing has changed mechanically, so it seems odd that the MBE is now seeing an error.
yes there would be a table stored for the previous run, it is constantly over-written with new data, the earlier scenario presented suggested that this data was becoming corrupted hence the poor starts. But you need to be able to view the table to find out, something you can only do with the tvr diags ..i'm not aware that any of the 3rd party diags software allows you to view this important info.
The fact is starts up as 0.4 as the value suggests that either the data has been wiped between runs, or more likely that no valid data was written to that area of the adaptive table previously.
I have just written to the nvram the values of plus 30 and minus 30 into the zero rpm line in the adaptive table on a cerb i have in here and as you can see those values are being read by the ecu without the engine running, meaning that whatever data is previously stored in the tables is being used straight away.
The fact is starts up as 0.4 as the value suggests that either the data has been wiped between runs, or more likely that no valid data was written to that area of the adaptive table previously.
I have just written to the nvram the values of plus 30 and minus 30 into the zero rpm line in the adaptive table on a cerb i have in here and as you can see those values are being read by the ecu without the engine running, meaning that whatever data is previously stored in the tables is being used straight away.
I've just hooked up MBETool again and looked at the values at initial power up and it's back to 0.4%. At the end of the last run they were -8.2% and -21.6%. I see you are using easimap 5. I've downloaded a version and will give it a try, hopefully it runs on XP. Many thanks
Edited by non_linear on Thursday 4th November 17:04
i doubt easimap will help you, i use a modified version which isn't the same as the one you can download.
you need the tvr diagnostics listed here :
http://tvr-cerbera.co.uk/software.html
you need the tvr diagnostics listed here :
http://tvr-cerbera.co.uk/software.html
non_linear said:
I've just hooked up MBETool again and looked at the values at initial power up and it's back to 0.4%. At the end of the last run they were -8.2% and -21.6%. I see you are using easimap 5. I've downloaded a version and will give it a try, hopefully it runs on XP. Many thanks
at initial power up ie ignition on engine not running ?Edited by non_linear on Thursday 4th November 17:04
it will likely be 0.4 in that scenario because the ecu will not learn a value at zero revs.
Or do you mean after initial start up ?
get the proper tvr software. The 3rd party diags are excellent for looking at live data, and they work on later windows machines and your phone and all sorts, but if you want to look at the stored adaptive tables you will need the tvr software on an old computer machine... i use xp.
spitfire4v8 said:
get the proper tvr software. The 3rd party diags are excellent for looking at live data, and they work on later windows machines and your phone and all sorts, but if you want to look at the stored adaptive tables you will need the tvr software on an old computer machine... i use xp.
Agreed. The complication is that the TVR supplied software is 16 bit. That means it works on XP, 32 bit versions of Windows 7 and 32 bit versions of Windows 10 (with additional libraries). It will not work on any 64 bit OS (unless in a VM) as Microsoft decided to stop support for 16 bit applications. If anyone has access to the original TVR source code, it would be easy to port and compile to work on later operating systems.OK, some progress:
Downloaded the TVR diagnostics recommended by spitfire. Reset the adaptive maps and checked they went to zero.
Drove the car for about 20 mins then with engine still running download the maps. Turn off ignition for about an hour then without starting car download adaptive maps and compare.
Two values have changed in the maps, at throttle 1.0 speed 750, and throttle 1.0 speed 1000. The rest of the maps have not changed.
If I cycle the power again, those same two entries change again. The same is true in both 123 and 456 maps.
TVR diagnostics tool shows the adaptive values to be 0.4 with the engine off, same as MBETool.
The AFR456 warning has now gone.
Table immediately after run, taken with engine running:
Same table after 1 hour, engine not running:
Downloaded the TVR diagnostics recommended by spitfire. Reset the adaptive maps and checked they went to zero.
Drove the car for about 20 mins then with engine still running download the maps. Turn off ignition for about an hour then without starting car download adaptive maps and compare.
Two values have changed in the maps, at throttle 1.0 speed 750, and throttle 1.0 speed 1000. The rest of the maps have not changed.
If I cycle the power again, those same two entries change again. The same is true in both 123 and 456 maps.
TVR diagnostics tool shows the adaptive values to be 0.4 with the engine off, same as MBETool.
The AFR456 warning has now gone.
Table immediately after run, taken with engine running:
Same table after 1 hour, engine not running:
That is the oddest thing, I have never seen that before that I know of (Ie it might have happened i've just never picked up on it)
I'm going to play close attention to this on the next car I do ..
What on earth can be causing only 2 table sites to be updated with new values with the ignition just cycled on/off ? Try a few more times if you can and see if there's any wild numbers generated. A change of a couple of percent won't make any difference, but say a -30 in there certainly would make a difference!
Well spotted, and proof that the tvr diags really is the best for proper diags work, you'd have never known that was happening otherwise without seeing the table presented that way.
Now all you need to work out is why it's happening at all!!
I'm going to play close attention to this on the next car I do ..
What on earth can be causing only 2 table sites to be updated with new values with the ignition just cycled on/off ? Try a few more times if you can and see if there's any wild numbers generated. A change of a couple of percent won't make any difference, but say a -30 in there certainly would make a difference!
Well spotted, and proof that the tvr diags really is the best for proper diags work, you'd have never known that was happening otherwise without seeing the table presented that way.
Now all you need to work out is why it's happening at all!!
Gassing Station | Tamora, T350 & Sagaris | Top of Page | What's New | My Stuff