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.
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
Bookmarks