I am attempting to acquire a EEPROM flash dump from a legacy Motorola MCU using an Arduino Uno Genuino, but when I connect a common ground from the boards pin header to the Arduino, the 5V rail (Vdd) collapses as if there is a draw coming from the Uno. When I disconnect the common ground, power down the ECU and restart it, the rail returns to 5V as it should.
Im not sure why the Arduino would be putting a draw, dropping the rail voltage. It does this whether the Uno is connected to the computer or not.
I feel it must be a hardware issue but unsure how. I tried to install some 330ohm resistors into the connections, thinking i had a ground loop or interference but they did not resolve the issue.
Im not extremely experienced, and hopefully there is something Im overlooking that a more experienced person can help me find and understand.
Check for unintended current paths between the Arduino and ECU; connecting grounds directly can create a short if Vdd lines are tied or if any pins are configured as outputs driving 5V. Use series resistors or level shifters on signal lines, never connect Vdd rails directly between boards, and verify the Arduino pins are not sourcing/sinking current before connecting. Also, measure voltage on each pin relative to ground before connecting to ensure no backfeed occurs.
The drawing is terrible, just threw together on break quickly. I realize that I could have done a better job of orienting it, apologies for turning the paper while creating. If I need to make something better I can, but this shows how it's connected from onboard chip header to Uno. All connections are solid, verified.
I did not connect the two rails together, no. All of the Uno pins are configured in the sketch to stay idle/safe while waiting. In operation some will be input and some output of course. The ECU itself shows high across almost all of these pads at 5.02vdc, same as board pad #1, Vdd.
What I'm describing happens when the Arduino is connected to the ECU but not connected to the laptop USB power, so I'm stumped on why this happens. Basically the Uno's just sitting there not doing anything but the minute I hook up the ground things get undesirable let's say
Yeah, it's a terrible drawing. I fix it so that the onboard pin labels are reading the correct direction when it's rotated clockwise. I didn't realize until I got to the end that I did something silly.
Yes to answer your question the ECU is powered while they are Aruino is just sitting there. I was actually curious if my powering up sequence could be part of the blame.
Edit: I made the drawing slightly less terrible. I'm not an electrical drafting pro at all; all of my drafting experience is related to mechanical engineering.
Thanks for the fix. That makes it easier to interpret.
If you are saying that the ECU is powered but the Uno is not and that the grounds are not common then when you connect the grounds the 5V collapses then I can see how that would be a problem. At the very least both should be powered simultaneously.
Powering the Uno while connected to USB and the ECU 5V is common to the UNO’s is something that could be problematic as well.
The grounds are common once the pin is plugged in, but initially the Arduino has no ground, correct…. Without being plugged to the usb.. If you look at the rough schematic, pin 8 is a ground that I've confirmed is common across the board and back to the actual battery being used to power up the ecu. I have been very slow in making changes to this setup I'm trying to be conservative because the ECU is a legacy part that's out of production and I don't want to ruin it.
Powering both simultaneously is something that would prove somewhat difficult because the ECU requires a key in order to power up the MCU. It's a simple normally open switch that is closed magnetically. I could substitute a jumper there but it still wouldn't be automatic for precisely simultaneous starting.
I have also never tried to power the ECU with the magnetic style key in place already. I think that that would work as sort of a short Gap easy fix on that, but the bigger question would be how do I start the ECU and the Arduino at the same time when the ECU requires a physical 12v connection to a battery?
That’s definitely a problem you are going to have to solve. If you power the Uno from the ECU the way your drawing shows, being careful not to have USB connected then it and the ECU will get power simultaneously. I think.
That will cause you to need to be very careful during program development so that you connect and disconnect everything in the right order. Prone to disaster unfortunately.
I’m going to wait for other helpers to chime in as I could easily have misinterpreted some of your setup and be giving you bad advice.
Unfortunately I don't think that the ECU is capable of powering the Arduino. I connected it that way through an ammeter and it showed the power consumption for the Arduino to be approximately 150 milliamps. I don't think the ECU was designed to have any extra gear like that powered directly off the vdd line. That line is regulated to 5 volts. Anything else anywhere on the board that comes from the battery is of course at 12 volts.
The upshot here is that what I'm really doing is attempting to locate the ignition timing maps that are stored in the mcu. The reason I want the dump is so that I can look for the signatures of the table. It's a very simple ECU that only changes ignition timing and a few other minor parameters. I have the manufacturer's Diagnostics tooling, so my plan was to take a dump, go in with the diagnostic tool make some changes and then take another dump to ascertain where those tables exist. Basically I think the same way that people do it with more complex Automotive ecu's with 3D mapping and so. This should be more or less a simple 1D map as it just changes the ignition curve based on the tachometer signal. To program normally or rather to program once I know, I will build a GUI to pull those addresses, allow me to alter the values and then upload them to the ECU. What I'm trying to do basically is to look at addresses in memory that the diagnostic tool doesn't bother looking at. I just don't know where to look
That could be the problem. From your explanation it sounds like the manufacturer’s tool allows changing but not reading back some of the ECUs tables. Is that correct?
Exactly. Basically it's got canned profiles that I am able to select which profile I use let's say for ignition timing there's a map or a table. I can choose between any of the four that were included from the factory, but I can't change them. I know however that the tables are editable because there were a couple of factory race teams back in the day that had the ability to do that. Unfortunately all of those teams have since disbanded and each of them that I have contacted has lost or thrown away the software on an old pc. I mean we're talking about stuff that people haven't really wanted to do for 20 years. Nobody really cares because it's old two-stroke stuff. I've exhausted every connection that I have in the industry so I had to start from the ground up. In theory it's not that difficult but in practicality there are some subtleties that make it a little bit challenging.
But to dovetail with what you said yes, it calls some addresses out and allows the contents of those addresses to be edited, some addresses it calls out and then just allows a selection of which profile or table is being used, we could call those switching addresses for the tables themselves, but it doesnt call up the table addresses bc the ECUs were built for the average consumer, not a tuner.
the target addresses are not called up at all or they are called but not displayed in the factory disgnostic software, but theyabsolutely do exist and are rewritable. I want to identify those addresses, call them up, change them and then reload them. It's something a tool very similar to the factory tool can do with no problem. Like I said I know it was possible because software dedicated to just that purpose alone was in hands of some of the factory race teams Once Upon a Time
I understand.
What sort of device are the tables stored in? If it’s that old, it sounds like they may be separate from the processor and could possibly be dumped and reprogrammed using another scheme.
It is stored but I believe on the actual MCU in the 32k eeprom Flash memory.
There is one small 2kb rom chip located just a bit away on the board, but it was a well documented device and I was able to find an Arduino sketch to dump it. I did a dump and it did not contain anything that even closely resembled a table.... nothing I really saw as a lot of value, I did take a look at it in a hex editor but I don't remember at this point what the contents were, but I didn't feel that it was enough at the time to even have the tables.
While you are doing the schematic, also label the "legacy" MCU, Motorola had several different families with many members in each. What is a "EEPROM flash dump", that is two different types of memory and they not the same. Also some of the Motorola processors were protected from an external source getting there code.
An annotated schematic as @Railroader requested labeling every part. Also a schematic of the circuit the legacy processor came from or at a minimum a description of what it did/does. Are we talking about a MCU (Micro controller or ECU Engine control unit). If it is a ECU where is it form, Motorola sold millions of microprocessors for ECUs.
