|
Home
Embedded
Serial Comm.
TPU uc
FI Equations
Board Testing
Miscellaneous
| |
| |
Notes on TPU microcode for the 4-layer board
Source :
- The current microcode is a modified version of the Bosch 58XX microcode archived
at the efi332 site. The reason
for the modification is that there is not enough room in the 2k onboard emulation RAM
for all this code plus the SM, ITC, and RWTPIN functions also needed. To make this
all fit, something had to go and the psp35 function was removed and psp12c modified to
include an initialization routine that is needed from psp35. The mod was done by list
member Ian Murphy. Its a bit of a hack since neither Ian nor I are microcode jockeys
but it does seem to work well and makes it possible to everything to fit.
- The RWTPIN function is taken from the Motorola archives for misc functions.
- TPUMASM was used to compile the archived functions and S19TOC (search the web for
this one, I can't remember the URL) was used to translate the S-records into the array
in emuram.h.
Resynching :
- The Problem : The documentation for the 58XX functions is a little contradictory
with respect to the ability of the PMMX function to resynch in the event of an error
code. It says that error codes do not affect the resynch condition, however
in operation, resynching and normal operation does not occur in a large percentage of
the cases following an error being posted. In other words, you can't depend on the function
to keep working after an error occurs as in the event of a stall.
- The Fix : The PMMX function is configured to generate interrupts and an ISR installed to handle the
various error codes that the function generates. Testing has shown that the sync-stall code
(0x84) is the black hole for this function and once encountered, the function has difficulty
keeping track of rpm. Stopping and restarting the function enables it to resynch and
normal operation can then resume.
- Complications : The problem
here is that an immediate shutdown and restart of the PMMX function can leave the PSP lines in
an indeterminate state and if left high on either the spark or fuel lines, disaster could result.
Because of this, a series of actions are taken before restarting the PMMX function.
The first action taken is to immediately force the injector channels low to stop them from firing further. These
can be closed immediately with no downside other than potentially one lean cylinder firing. The
spark channels are then checked in turn for pin state. If the current pin state is low, the PSP
function is disabled and the pin forced low using the RWTPIN function which configures the pin
as a discrete output. Here again, the PSP channel documentation indicates that the PSP function
has provision for forcing the pin low without disabling the function but the microcode to
implement the function is missing from the microcode.
If the PSP pin is currently high, interrupts are enabled for that channel
and the corresponding ISR shuts the channel down upon the next high to low transition when
the interrupt is generated. In practice however, the pin state bit maintained by the PSP
function does not appear to ever be set low (this is a potential bug in the microcode) so
in all cases each spark channel currently fires once after the initial error code is generated.
After the last PSP function is disabled, the PMMX function is disabled and restarted. This whole
operation takes place inside one crankshaft revolution. See module isr.c for the PMM_ISR, and
PSP_ISR routines.
Other Ways of Forcing PSP lines low :
- Setting END ANGLE out of range : Flat out does not work - results in the
line being left high all the time.
- Setting HIGHTIME = 0 : At startup before the PMMX function has been exposed to any signal, this
works but if the PMMX has seen signal, setting HIGH TIME to zero produces a high frequency
periodic output on the pins. The documentation indicates that the frequency of this behavior
is dependent on the TPU latency.
- Using the PSP force mode : During startup, reset, or when a PMMX error code is generated the PSP function would
ideally be setup to force the line low. The 58XX documentation has a description of how to do
this. Unfortunately it appears that this action causes
the TPU line to be forced high. According to Rod Barman, the author of the microcode, the
code necessary to do this is missing from the function. If we can get a microcode
programmer to fix this, that would be the preferred method because it would obviate
the need to shutdown and reconfigure the TPU channels.
- Using the buffers to block signal : The first method used in the code is to make use of the Port E pins as discrete outputs and use them to
switch the enable pins on the 74HCT125 buffers. This method is used at powerup to prevent
any spurious firings due to unknown TPU pin states before the TPUinit function is executed.
A simple hardware mod to the board can be made to hold the buffer enable pins high during
powerup and reset to disable the output and a pull down resistor on the driver side then
takes care of the line. At shutdown upon the sensation of low and falling voltage, the buffer
is also disabled. This is a sure fire method but because of the need for mods and the number
of CPU pins required another means is used for cases other than startup and shutdown.
- Configuring Pins as Discrete Outs : This method is used
during the periods between startup and shutdown. Two functions could be used
to accomplish this, DIO or RWTPIN. Since RWTPIN is slightly smaller,
it is used here. Pins are configured as discrete output lines and forced low by the function
itself. Its ugly, but it works.
Back to top
|
