Quote Originally Posted by kur4o View Post
So 144436 must be the father of later style PCMs ignition chips. They also contain all the cam,crank sensor inputs and I guess there is a fail safe mode built in, for spark, based only on opti signals.
What will be interesting to find is there are a built in second channel or total of 4 channels of spark control for waste spark setup, like the northstar dis system.
I remember there were some empty pins that have no connection. Maybe tracing the outputs to the board undefined pins will reveal if that was left on the table.
The format of the low res signal suggest a waste spark setup. The 4 pins to the ram expander might drive the 4 outputs and the 2 pins to tpu can be used for configuration. Later style ignition chip can be software configured for single coil, waste spark,multi coil setup for v6,v8 signals.
It may be that the chip looks at the incoming Opti pulse stream and tests for errors. It can sample the hi&lo res signals with eclock (it is connected) and count the transitions. When I was working through the port replacement unit there were a couple of spots in the $1807 register (I call that port D) that I could not understand. Also a couple of pins that connect to the ignition chip that I could not toggle. My thinking is that both the ignition chip and the PRU are connected along with pull up resistors. That makes the lines multi-drop such that the TPU or the ignition chip can tag the opti as bad. This morning I will apply the opti signals and see if I can change the state of the two lines. This will at least bring me closer to proving both the opti simulator and understanding the ignition chip. Problem here is that there are so many un-knowns.




Quote Originally Posted by kur4o View Post
On the dwell failing.
The irq routine shares data bidirectionally with TPU, like the firing cylinder id and all other configs. If it doesn`t run in bootstrap the dwell tests might fail for that reason.
Could it be possible that you enable execution of irq requests in bootstrap mode or it will be too much hassle.
I am running my own ISR. It is very limited at the moment, just clearing the interrupt and returning. Yesterday I added some register reads to the ISR, nothing interesting yet. I can not run the GM ISRs because they use the RAM that I run my program from. This all will crash once the code is over-written. If you have specific actions that I should include in the ISR, let me know. Also I am using only one of the four interrupts that the TPU can generate. I need to spend some mind time looking at the GM ISRs and try to figure out the intent. At some point I will need to write routines to re-flash. At that point all the constraints re code size and so on will go away. At the moment I have few bytes that remain before I need to change from bootstrap of code to bootstrap of a loader + load into PRU ram ($1810 --> $1FFF)


-Tom