Fake EPROM

As mentioned in the main UltraMod 4 project page, one of the key points in this new hardware version was to make an RP2040 processor chip appear like an EPROM to the ECU on my Aprilia motorbike. Rather than built a complete circuit board, I developed a proof-of-concept codebase running on a Raspberry Pi Pico board. It uses the same RP2040 processor. I needed to prove that my memory timings were OK before committing to the time and expense of a new circuit board design.

To verify that my timing mechanisms were correct, I added a debug output signal to one of the few remaining GPIO pins on my Raspberry Pi Pico test board. The debug signal would be driven high as the first thing after the CPU would wake up after it noticed the start of a new 68HC11 bus cycle. It would get driven low again when the bus cycle was completed. The completion time would be defined by the specific bus cycle being performed:

Null cycle (if the Eprom was not being addressed)
Read cycle targeting the Eprom
Write cycle targeting the Eprom

Null Cycle

The 'null' cycle occurs when our fake Eprom detects that it has not been addressed by the current bus cycle.

The bus cycle starts with the falling edge of the 68HC11 E signal (the lower signal on the scope display). The fake Eprom software wakes up and drives the debug signal high (the top trace). After waiting for the Eprom Chip Select signal to become valid, the software determines that it is not selected, and drives the debug signal low again.

You can see that it takes 64 nanoseconds (8 processor clocks at 125 MHz) for the software to wake up after E falls. The entire null cycle takes about 176 nS (22 clocks).

Read Cycle

The 'read' cycle is when the 68HC11 processor in the ECU reads our fake Eprom.

The wakeup time is identical to the null cycle. The software needs to delay until the address driven by the HC11 is known to be valid according to the HC11 timing specification. At that point, the software reads the address bits from its GPIO inputs, then extracts the address, looks up that address withing a 32K element table containing the original Eprom contents, grabs the Eprom data from that address and writes it to the GPIO outputs so that the 68HC11 can read it. When all of that is done, it drives the debug signal low again (top trace).

The scope shows that the read access time is a bit better than 240 nanoseconds. This is significantly better than the 68HC11's requirement of 395 nanoseconds (max) measured from the falling edge of E.

Write Cycle

The 'write' cycle occurs when the 68HC11 ECU processor generates a write transfer to our fake Eprom. Just like a real Eprom, write cycles like this will not update the Eprom's memory contents. Instead, our fake Eprom interprets a write to mean "please log this interesting fuel injection data". It is up to the HC11 firmware to define what a write might mean. For example, a specific address would be used to indicate the write data corresponds to the current throttle opening. Each kind of data produced by the ECU gets its own specific address.

The write operation takes the longest because the HC11 bus specification indicates that the write data will not be valid until 80 nanoseconds after the rising edge of E (bottom trace). Once we read the data off the bus, we send it to the other core for logging, then drive the debug signal low again (the top trace).

That's all there is to the fake Eprom. All in all, it only has 3 basic operations to perform! In its current version, there are a grand total of 31 machine instructions for the main loop on a processor that has 2 megabytes of instruction memory. From a memory space perspective, the processor is completely underutilized. But from a time perspective, it is actually quite busy: it needs to wake up and do its job 2 million times a second.

Given that the proof-of-concept was a total success, it was time to make a circuit board.

Google Sites

Report abuse