EFI hacking engine and transmission simulator

I’m going to be building a simulator that will allow the engine / powertrain control module ( ECM, PCM, ECU )to operate correctly when not installed in a vehicle.   This is required since in many cases, when the software in the PCM detects that the sensors and inputs required are missing it will go into shutdown or limp mode and prevents normal behavior of the module.

As I have more experience with Ford fuel injection, in particular the prior generation EEC-V systems I will be starting with that target in mind.  Most of the ideas exposed here will be applicable to other vehicles and nearly all engine control use similar sensors and basic design.

To begin, I pulled out the PCM, wiring harness and dashboard I have been using for bench testing and laid it out on the table.

What an unruly mess.

I’m using an old Toshiba laptop power supply, it produces just shy of 15v which is well within the operating limits on a vehicle at 4 amps and is light and portable.

I’m going to start with an ST Discovery board, the STM32F4DISC0 with the color LCD and touch screen, not because I need that much capacity but because I have it already and the cost was quite reasonable.

One excellent feature of these STM32F4xx chips is that they have a bunch of programmable timers which can be configured to do pulse trains and synchronization.   This will come in handy as we need to provide a stream of pulses with one missing pulse along with another synchronized single short pulse to emulate the crank and cam sensors.



Perpetual tools maintenance

When it became obvious that just using the AT commands and built in WiFi capabilities would not be enough to realize this project I investigated what would be needed to build new binaries for these PADI modules. Not a very complex system, compared to most but it does include a SOC, WiFi module and RTOS all rolled into one binary. Thankfully there is an available build package for this chip from Ameba.

To build the Ameba binary I needed some libraries for cygwin which forced an update to that package. That build went flawlessly. Building OpenOCD under cygwin for the command line revealed that this version does not support the STlink. The prebuilt Eclipse OpenOCD needed a newer version of Eclipse which forced upgrades to the Android SDK which required a newer Android Studio. The STlink V2 needed to be upgraded which required new drivers and utilities. All of this to get to the point where I could just verify that the rebuilt package matched the binary on the device and functioned.

It isn’t developing for these platforms that’s difficult, it’s maintaining the toolchain…

Computer controlled Christmas lights using PADI stamp

A fun and quick project for the IoT space is a lighting controller for the holidays.

The goal is to have multiple strings of lights, each controlled centrally yet installed on the house and various trees separated by up to 200 feet. Each string should be addressable and synchronized. I’m not going to address weatherproofing as these will be run from GFCI outlets but they must be safe to install and handle.

Lights themselves are inexpensive. Extension cords add up quickly. Assume we have 4 locations, each with 4 individual light strings and each location is spaced 50 feet apart. Bringing all of the cords in to a single central 16 channel location will require 16 cords, 8 75′ and 8 25′ cords plus the length to go up each tree. That is a large bundle of cords and at roughly $0.50 per foot, 800 feet of cord for at least $400.00 in just cords. A bit more than what I want to spend for blinking lights.

Plan two will have 4 smaller 4 light controllers, one per location. Daisy chaining the cords can decrease the required length to 200 total feet of power cables. We then need to optimize the light controller design to build 4 of them and make them wireless.

Initial draft idea is to use an project enclosure, cable tails to outlets and the PADI stamp controlling relay modules. While certainly workable this draft ends up being moderately expensive.

Project box, 4x6x3: ~ $8.00
Cord tail outlet, 1 per module: $20.00
Cord tail plug, 1 per module: $11.00
Cable inlet / grommets assy, 5 per: $5.00
Relay module, 4 ch opto 3.3v in: $8.00
PADI Stamp with breakout board: $2.00
USB 5v-3.3v regulator: $1.00
modified USB 500ma power adaptor: $0.00

This works out to a total BOM of around $50 each unit. There has to be a cheaper way, off to the hardware store.

Heavy duty 2 gang new construction wiring box, Carlon 34 cu in: $2.18
120V blade wall outlets, 15A 2 per module: $0.50
2 gang outlet cover: $0.50
8′ extra outlet extension cord: $5.62
Relay module, 4 ch opto 3.3v in: $8.00
PADI Stamp with breakout board: $2.00
USB 5v-3.3v regulator: $1.00
modified USB 500ma power adaptor: $0.00

This gets the cost down closer to $20 each and decreases the hassle with huge bundles of power cords running everywhere. There is enough room in the wiring box to easily fit the stamp, relay module and USB wall wart inside and they come with a convenient nail bracket to attach to the trees. Cutting the hot side link on the duplex outlets allows the individual sockets to be isolated.

Simple, straightforward, somewhat elegant and yet inexpensive. I think this is good enough to build and test.

Pine or Pi?

The absence of analog interface features and incompatible GPIO interface preventing use of the Pi software modules hamper use of the Pine for casual IoT hacking.

Another nuisance is the lack of Wifi onboard.

Given that the processor and memory specs on the Pine exceed those of the Raspberry Pi 3 B+ these weaknesses mean it will be hard to find a good use case for the Pine over the Pi.

Deeper into GPIO and the A64

Let’s see what the kernel thinks we have configured for the gpio interface that is letting us use the virtual filesystem driver. Using the kernel’s built in debug filesystem interface we ask it what the config is
root@pine64:/tmp# cat /sys/kernel/debug/gpio
GPIOs 0-255, platform/1c20800.pinctrl, 1c20800.pinctrl:
gpio-80 (sysfs ) out lo
gpio-166 (1c0f000.sdmmc cd ) in lo

GPIOs 352-383, platform/1f02c00.pinctrl, 1f02c00.pinctrl:
gpio-354 (wlan_regon ) out hi
gpio-355 (wlan_hostwake ) in lo
gpio-356 (bt_rst ) out hi

GPIOs 1024-1027, platform/pinctrl.1, axp-pinctrl:

So we see that gpio-80, our LED from the prior post is ‘owned’ by sysfs since I didn’t unexport it, and is an output and currently logic low or 0v

Looking deeper into the kernel config we find many more config files in the filesystem tree in these locations
/sys/kernel/debug/pinctrl/ and /sys/kernel/debug/gpio/

To find out what the kernel is really talking about on these interfaces we shuold go to the source and read the documentation. https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/tree/Documentation/gpio/

Our A64 ia also known as a sunxi50i

Using GPIO on Pine64 from node.js

We can use a module already built that leverages the file system driver to run our LED and make it blink.

One such module is called ‘onoff’ which can be installed with npm

Here is a brief node program that blinks the LED at 1 hz ( 500 ms on / 500 off )
var Gpio=require('onoff').Gpio;
var led = new Gpio(80,'out');



var LED=false;
function ticktock(){
// turn on LED
else {
// turn off LED

Simple and functional although it must be run as root, if you don’t need anything too fancy this will be sufficient.

PineA64+ nodejs and npm installation

I like the event driven programming paradigm used by node.js, it is well suited to embedded control and many real world problems.  The version of node included in the previous post’s image does not have a working node package manager npm so we will need to install one that has access to the world of node packages.

First go and download the node.js sources from https://nodejs.org/en/download/ chose the Source Code option.

Open your terminal window. We then unpack the sources, configure and build node which included npm. If the build works, we remove the existing one and install the update. Build does take quite a while. If it fails, check for and install any missing packages.

node -v
cd /tmp
tar -xzf /home/debian/node-v6.9.1.gz
cd node-v6.9.1
make test
node -v
./node -v
sudo apt-get remove nodejs
sudo make install
node -v

The result should be node running the current version instead of the oddball obsolete version.

You can now start installing the node packages you like using npm as usual

nodesource.com nodejs installation method fails on pine64

As of November 22nd, 2016, this method does NOT work on the Pine64 as the nodesource repository does not have entries for arm64.

The commonly posted method for installing node on the Raspberry Pi is to run the script located here https://deb.nodesource.com/setup_7.x piped directly to bash from the command line.

I do not consider this pattern to be safe or sane from a security perspective as you do not have control over what is in that script, even if you preview it in your browser as they could serve different versions of the script for wget versus Chrome. If you want to use their automated script, and I do generally think that it is reputable and safe, download the script to your /tmp directory and review it before running it.

That said, until they add the binary-arm64 builds it will fail with the following error.  Use the manual compile method described in my other post.

  Unable to find expected entry 'main/binary-arm64/Packages' in Release file

Blinking lights on the PineA64+

Now that we have a running Linux system on our Pine64 we will want to do something fun with it.  As a hardware hacker, one of the first things we do is to make an LED blink, the equivalent to “Hello World” in straight coding.

The PineA64 uses a System on a Chip SOC from AllWinner which contains an absurd amount of complexity and more features than you will likely ever use.  Thanks to the abstraction layers in Linux we have a somewhat simple route to access the General Purpose Input Output GPIO pins, the System Class virtual filesystem drivers.

We will use a T-Cobbler board to bring the Raspberry Pi connector out to a breadboard.


Now we do have a bit of complexity here, the mapping between the connectors on the board and the pins on the SOC are not direct or obvious and they differ from the Raspberry Pi locations, even though they make an RPi port available.  We are going to use the Pi pin labeled #26 for our LED.  To map this to the Pine64 we can refer to this page’s chart: http://joey.hazlett.us/pine64/pine64_pins.html and see that this pin is number 80 on the Pine.


Wire the LED with a resistor in series between pin #26 and 3.3v.  I used a 1k resistor.  This will make ‘0’ on and ‘1’ off.

sys/class/gpio is the virtualized file based access mechanism we will use for our initial LED on/off test.

Sending the pin number you wish to activate to /sys/class/gpio/export will enable that pin and expose the virtual control files in the directory /sys/class/gpio/gpio80

From out trusty console we can type these lines to make the value at pin 80 change from floating to output and then set the values, toggling the LED connected there.

ll /sys/class/gpio
echo 80 > /sys/class/gpio/export
ll /sys/class/gpio
echo out > /sys/class/gpio/gpio80/direction
echo 0 > /sys/class/gpio/gpio80/value
echo 1 > /sys/class/gpio/gpio80/value
echo 80 > /sys/class/gpio/unexport

You should see the LED light when you issue the command to set this pin to 0.

We are half way there.  This interface can be scripted or even used in node programs as these ‘files’ can just be read or written to using fopen and fwrite.

A quick script to blink the led ( which must be run as root, ugh )

while (true)
echo 0 > /sys/class/gpio/gpio80/value
echo 1 > /sys/class/gpio/gpio80/value

The wise will note that there are no waits in this code. Running in this way pulses the LED about 280 times per second.

Probably fast enough for many things but I want to get this working with node.js