E38 - 24x Reluctor - 1x Cam - $$ Reward

[1fast72nova]

I want to run 58x on the older p01 or p59 ... Is this possible?

The solution today is to wire in the Lingenfelter TR-002 box or physically change the crankshaft reluctor wheel and cam sprocket.

Has anyone been able to find where the main crankshaft signal enters the program? If so why can't that waveform be intercepted and modified?

[antus]

It doesn't work like that. The handling of the pattern is in the design of the code. The code is in the interrupt handler where it must be very fast and there is not time (or hardware such as spare timers) to implement some type of translation layer in front of the factory code, the factory code needs to be replaced with code that handles different logic to suit the operating system. Not impossible, but takes very detail understanding of the code, strong assembly skills and a lot of time.

[1fast72nova]

It doesn't work like that. The handling of the pattern is in the design of the code. The code is in the interrupt handler where it must be very fast and there is not time (or hardware such as spare timers) to implement some type of translation layer in front of the factory code, the factory code needs to be replaced with code that handles different logic to suit the operating system. Not impossible, but takes very detail understanding of the code, strong assembly skills and a lot of time.

What is the "interrupt handler"?
I have code, in a different language, that finds the missing tooth and converts the waveform

[antus]

ummm ok.. so a single threaded cpu has a clock signal, a certain amount of megahertz of speed. For each clock 'tick' the logic machine that is the cpu applies all the binary logic in all its transistors and gets a step closer to completing the processing the assembly code tells it to do. It takes several clock ticks to do each operation. So you can think of the whole thing as a machine full of (electrically) moving parts, and the clock ticks crank it. Then, you have interrupts. Some are software, some are hardware. This is a hardware interrupt. So named, because it interrupts the main code and does something else. So the edge of the wheel, rising or falling, meets the analog voltage threshold to trigger the external interrupt which that input pin is connected to. At that moment, the CPU saves its internal state so that it can back to what it was doing when the interrupt handler is complete. It moves the instruction pointer to the interrupt handler address (which for most CPUs is stored a vector table in a standardised location). The interrupt handlers job is to do whatever the task it needs to do, as quickly as possible, before some other interrupt fires, to handle the interrupt and return to the main operating system loop. Also in the hardware there are timers. They just run on their own and count. So the interrupt handler saves out the counter of the timer and sets a flag in ram, to tell the operating system that the interrupt has happened and at a certain time, then it might reset the timer to restart it to start counting for the next event. Then it exits. This is general, the specifics might be more or less complicated in reality. It might only be 100 clock cycles to do this, when the cpu might be running at millions or hundreds of millions of cycles per second. Then the main code, which is going through its tasks in order, gets to the bit where it calculates spark and fuel. It sees something in ram that the handler left behind and it knowns that the trigger edge was seen, and at X time. It can then do its thing - calculate and program for spark, fuel, increment cylinder counters, whatever else it needs to do. And it can do it out of perfect sync with the actual trigger that came in from the engine bay as the timing information it needed was in ram.

So the hard part is, if you mess with this, you dont have time or an extra hardware timer to calculate a fake trigger in the handler (eg handling timing of the input signal and timing of a false signal), and generally how it all fits together might no longer be a clean fit, and might need more complicated work. This is because its OEM and the design criteria was not to make an infinitely configurable trigger. The design criteria was to be fast to execute to support only the OEM trigger. This is why its easy to do it in something like a megasquirt - the code had a design criteria to be infinitely flexible from the beginning. This is all general, if someone is to solve this maybe they do it by finding there is an unused timer, or some way to generate a different trigger they can pass to the OS from the actual one. Maybe they find there is enough time to put this code in the interrupt handler without causing some other crash. Maybe they find they can put it in the main OS instead. These are the challenges that need to be solved.

[1fast72nova]

That does sound very complicated. I'm really fond of the simplicity and accuracy of the p01/p59 PCMs, much much more than megasquirt and felt there was something not exactly right with the trigger coding or maybe in the trigger to spark coding. Not that I had access to the code, only from testing. I could find discrepancies that would occur randomly with regards to timing from cylinder to cylinder. On a 555 I had sometimes the #5 cylinder would lag and not fire until #7 would fire.
Anyways can you point me to where the code is for the interrupter?(I have or can get bins for virtually any p01 or p59) I'd like to set least take a look at it.

[antus]

We should stop hijacking this E38 request thread, but for the P01/P59 M68k cpu see https://www.nxp.com/docs/en/user-guide/MC68332UM.pdf
Look at the vector table on page 3-11. There are 7 interrupts labeled "LEVEL 1 INTERRUPT AUTOVECTOR" and so on up to 7. The offsets are from the start of the bin. Each vector is a 32 bit address. So you can look at the pin specs of the cpu, trace the crank signal from the pin on the loom connector back to one of those pins on the CPU to see which interrupt its on, and then look at the corresponding address at the start of the bin to find the address in the bin for that interrupt handler. That is where the signal is triggered and recorded by the handler.

Look at page 3-4 or 3-5 for the two package types. Look at the CPU in the PCM to see where the pin 1 dot is to see which one you are looking at, and see which pins are IRQ1 through IRQ7. IRQ = Interupt ReQuest
You can check the power pins are right with your multimeter as a sanity check when you think you have it figured out before you start tracing the IRQ pins.