Thought this would be useful as with values the way they are I can imagine a 20vt being scrapped for a failed cam sensor + it would obviously be useful to be able to drive the car after the cam sensor has failed, even if just to get it to a specialist for a sensor/belt change.
So I've been looking at the firmware code for a while now, working out if it's possible to force the engine to start without a valid cam sensor reading.
Obviously there's no way to tell whether the engine is in a compression or exhaust stroke based on the crank sensor reading alone, so there can only be a 50% chance that it'll start each time without the cam sensor. But I reckon a 50% chance is an acceptable alternative to a 0% chance.
So after wasting a week searching intently for code that didn't exist, I finally got it working and have been testing this week, so now with just a chip change you can have a 50% chance of starting the engine even with the cam sensor unplugged. The cam sensor error is disabled and either the engine starts as normal or just turns over without starting, so after a few seconds of extra cranking you just switch off and try again until it starts.
Of course when it doesn't start it's injecting fuel on the exhaust rather than compression stroke, so I wouldn't advise using this as a long term solution, but to get the car moving again I think it'll be quite useful.
For anyone else who's ever examining the Bosch Motronic code, I'll explain what had me hunting for non-existent code for a week, it may help...
Turns out they access the same external RAM address through 2 different types of address setup instruction. The normal 16 bit address DPTR register instruction but also with the high address byte in hardware port 2 coupled with the low address byte from the top half of page 0 RAM.
The DPTR register method is accessing either the firmware ROM or external RAM, depending on the address, as they eventually map in external RAM into the unused space near the top of the ROM address space.
Quite obvious when you know how it all works, but until then you just assume the 2 different methods are addressing different external devices mapped separately by the memory controller, rather than exactly the same byte in the same device.
So if you find code accessing an interesting external RAM address using one of those methods, you also need to search for access to the same address using the other method, or you could miss something important.
Having never hacked 8051 code before I found this guide to the 8051 microcontroller hardware architecture very useful:
http://www.mikroe.com/chapters/view/65/chapter-2-8051-microcontroller-architecture/Anyways, if anyone ever has a 20vt immobilised by a failed cam sensor, just drop me a PM.