BBB PRUs to emulate the ROM of Ford's Intel 8061/5 Microcontrollers

Jason/And others on the BBGG,

My name is Chris Grey. I work for an HVAC controls company called, Automated Logic where we use the AM3352 in our product and started our development of that project on the Beaglebone (white at the time). So I’m familiar with the BBs and have always thought they’d be a good platform for a personal side project. After watching your videos about the PRUs, I think that project is within reach of giving some time and researching in earnest now. I’m also a DIY Ford computer tuning enthusiast and admin of a forum hosted at which is dedicated to people discussing Ford EEC computer tuning for high performance street and racing applications.

As I’ll detail more below, I think I have a good fit for the BBB and it’s PRUs. So I’m in the research phase of learning everything I can about the PRUs and how they interact with the Cortex A8 and the GPIOs.

I’ve watched the videos that were posted up on the website where you gave a presentation about the PRUs. It was a good start to an intro, but it didn’t cover some of the details I was hoping to see. Here are the bullet points of things I thought could be improved in the presentation…and many may have been by now.

  • Intro to the PRU assembly and the documentation where the Operands are discussed

  • A bit more in-depth coverage of the C/C++ compiler (don’t care whether it’s the TI or GCC as long as it compiles to usable code)

  • Specifics of how to load a C-compiled or Assembled ELF into a PRU.

  • A bit more about the shared memory between the PRUs (maybe just a slide on the memory map of the PRUs that points to where the 8k PRU memory is and where the 12k shared is (no more than just show that assuming it’s that simple)

  • Quick discussion about GPIO. The memory mapped GPIOs are fairly self-explanatory, but how are non-memory mapped GPIOs accessed by the PRU?

  • When using the PRUSpeak Linux driver as a starting point, talk about the things most likely to change in a custom application vs the things you recommend that probably shouldn’t be changed (if any). The thing I wouldn’t expect you to speak on is the details of making Linux drivers. That’s well covered in other areas of the Internet…no reason to re-cover what’s already been done.

  • I’m also a little confused between RemoteProc using the stack and messaging and the shared memory technique. Messaging seems more flexible and it also seems like a lot of the memory management details are abstracted away. Is this just the “newer” thing that wasn’t available when you made the presentation where BotSpeak was discussed? If so, that’s understandable.

If you have newer presentations where some of this is covered OR you can link me to where I can get some of these answers, that’d be great. From these videos and the website, I’ve re-imaged my BBB and actually walked through the BotSpeak exercise you did in those presentations. Being able to pause and replay made watching this way even better than actually being there, so please don’t hesitate to post up presentations you do in the future like this. They are valuable…probably more-so to people online than to the people in the class.

Anyway, here’s the problem I’m hoping to solve. I’m a Ford EEC tuning enthusiast. Right now, the only options for retuning many of the older Ford EECs is to work with the stock tune that came from the factory and change parameters within the tune. The way this has been done is somebody has to disassemble the assembly and Ford did a LOT of things in their assembly that make disassembly not easy. Some claim they were performance enhancement techniques, others just claim it was their attempt to make disassembly hard to do. But like most good hackers, people figured it out and from there, we found the memory offsets of the parameters we care about. Using a spreadsheet we map the parameters, put english descriptions to them, and formula translations so we can convert 16-bit values like 12000 to something meaningful like 5.1v. Then there’s software built around those spreadsheets to do the work for you. And finally the hardware part where the modified tune is written to a chip that over-rides the EEC’s onboard PROM chip and, instead, feeds the processor the modified tune. That’s worked, but it’s very limiting in that you can only do what Ford programmed as options to change. If you don’t like their actual algorithm, practically speaking, it’s just not feasible to change the code.

Anyway, what I’m wanting to do is harness the power of the PRUs to speak to the onboard processor, a Ford-specific derivative of the 16-bit Intel 8096, called Intel 8061 (single bank) and 8065 (4-bank capable). They range from 12MHz to 24MHz clock cycles, where the 8-bit memory-bus runs as 1/3rd the processor clock. I want to, on the fly, emulate the PROM by sending the processor opcodes and operands that basically marshal data to/from the Cortex A8 and the EEC’s processor’s I/O thus relocating all the engine management logic to code running in the Cortex A8 and turning the EEC’s processor into a slave co-processor that does nothing more than read the inputs, write to outputs, and inform of events (i.e. interrupts). The details of how that can be done, I think I have a good handle on.

From what I can tell this is similar to the 6502 slave memory project that was done. The difference is this processor uses only 8 data/address lines, not 8 instruction lines and 16 data lines. While this complicates the programming, I’d think this would vastly simplify the board pinout.

What I don’t have a solid handle on is the Linux Driver, PRU programming/management, and GPIO pin management aspects. I know I want to use the PRU memory-mapped GPIOs so I can read/write 8-bits of data at a time since I only have 8 pins that will require bi-directional data flow with the EEC’s processor. There are 4 control lines that will be dedicated inputs and thus the PRU will only read them and so I’m assuming these can be any GPIO, not necessarily memory mapped.

At this point, it’s just getting the technical pieces all understood so I can plan out the data-flow strategy from Cortex-to-PRUSS-to-8061. It’d be nice to leverag as much already-written open code as possible, but I don’t want to force square pegs into round holes. Once I can see I can send the EEC processor lucid opcodes & operands and witness it responding to those opcodes correctly, I can start the fun part, which is actually writing the memory management and datalogging code up in the Cortex. That statement glosses over a LOT of technical things, but for the purposes of this discussion, I’m boiling it down. For those curious to know more about the Intel 8061/5 processors, here’s a link that goes into fair detail about their architecture:

The EEC Memory Control section will probably be the most relevant to this discussion. Much of the other stuff discussed are more application-specific to the EEC being an engine management device.

The absolute end-game is to get an architecture sophisticated enough that in 5-10 years, custom hardware could be made to completely replace the Ford EEC and run a high performance, open sourced engine management control logic that’s brand-agnostic so you could adapt the product to control Chevy engines, Toyotas, whatever, and interact with it using modern day conveniences like Bluetooth or Wifi.

In the case of my truck, an 89 Ford Ranger that I’ve transplanted a Ford V8 into, the computer that’s in it (an 89 Mustang EEC) dates back to the mid-to-late 80s. The repair companies that reman these EECs have already dropped support for this era controller. So when these EECs go bad, they are bad. The average Joe motorhead generally doesn’t have the desire or skill to diagnose and replace components beyond, say, an exploded cap. So having a modern aftermarket solution that’s BETTER than the open sourced solutions out there now would be desirable. The best open source project out there now is MegaSquirt, and that technology and project dates back 20 years. It works, but it’s antiquated and only marginally less cryptic than dealing with the stock Ford programming.

Anyway, that’s my project idea. And I’d like to learn more about the PRUs because I think they could be the key to me making this actually possible. I’m scrounging the TI website and any other wikis I can find as well as following any links that look interesting. But any extra reading or videos I can get would be greatly appreciated. And if you know anybody else that’d be interested in participating in a project like this, let me know. I could definitely use help. This is not going to be an easy feat and there’s plenty of opportunity for collaboration even if you aren’t a motorhead.

Memory Maps of the PRU RAM exist in documents have you read them? Why would you expect one small part of a complex Soc(The PRU) to explain details of Whats always described in the device TRM. Its amazing someone who hasn’t read all the documents is now offering tips on how to update the documents :blush:

I can't really help you (don't own a Ford and have no experience tuning
EECs) but this sounds pretty interesting. As I was thinking about it, I had
some questions.

As far as I understand, the original EEC effectively runs a simple RTOS,
and probably can be thougt of as a bunch of coroutines that each serve some
engine management function: one might be receiving the crank angle sensor,
another would calculate the timing sequence for current external conditions
(temperature, RPM, etc), and yet another would activate external devices
such as the fuel injector and spark coil, based on this timing. To replace
the OEM EEC you'd need to know the details of all the components. After
all, if you exceed their design limits, you could damage the engine (e.g.
if you consistently pre-ignite and knock the engine to death).

You seem to suggest fooling the EEC by giving it synthetic data and
instructions; I think you are trying to use the pieces of code in the EEC
that are presumably correctly written for the engine by its manufacturer.
This is clever: you treat the EEC as a library interfacing to specific
low-level engine hardware. Another advantage is that you don't have to
replicate the weird analog electronic interfaces to various sensors and
actuators, but rather use the ones already present in the EEC.

Is my understanding correct so far?

How are you going to deal with the following issues:

   - I believe you still need to disassemble and reverse-engineer enough of
   the EEC code to identify those individual services, so that you can call
   them out
   - the individual services are probably inter-related, and may depend on
   each other rather than decomposing cleanly---e.g. the spark routine may
   depend on being called within 1ms of the fuel injector activation.
   - the OEM EEC code probably contains some integrity checks like
   watchdogs and inter-coroutine checks, so you will need to fake them out.