looking for some guidance with an idea i have

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

to start im new here and have very little experience in this so please bear with me. what im looking to do is design and implement device that takes place of eproms in an car ECU allowing them to be flashed over USB. the one atmel device i discovered that lead me here is the AT90USB646 so thats why im here. the thing here is i need to essentially flash 2 different eeproms as the cars computer has 2 separate processors and eeproms so i need a way to differentiate where one flash belongs instead of flashing both with the same data. the second idea is to have one large flash and a way to sort of split it in half somehow between both sides of the ECU. yes i want to get rid of eproms and use surface mount flash chips because im limited on space. 

now the other problem here is the one chip because its an 87c257 latched eprom stock and a standard 27c256 does not work at all on it without a special adapter. in the past i have used a 74HC373 tri state latch to adapt that side to allow the use of standard 27c256 chips or SST27SF512 EEPROMS. so with that information would be be possible to put the 74HC373 in line as usual with a flash on that side than when the flash itself needs programmed flash it on the back side before the 74HC373 latch and pray that the latch being in circuit doesnt affect the flashing process? yes i know this is a lot for a first timer. any insight would be great. thanks. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

also i forgot to mention that one chip is a 27c512 stock and the other the 87c257 latched chip. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which ecu are we talking about? Sounds like a 90’s vintage one. It would probably be easier (and cheaper) to replace the ecu with a megasquirt or similar.

Nevertheless, if you wanted the means to change the chip data live, then you’d use a ram chip. Wifi or bluetooth would be simpler than usb methinks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

VWnut8392 wrote:
to start im new here and have very little experience in this so please bear with me.

 

And you want to take on a project like this?  Impressive.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We all built EEPROM emulators back in the day.  Usually you held the target device in reset and wrote to a 62256 SRAM that had some 74xx logic around it with an LPT port.

 

I am sure there must already be someone who has published an up to date design with a USB port on the interwebs already.

 

Google "EEPROM Emulator USB"

 

Though I imagine all the *cool kids* already have bluetooth or ESP8266 WiFi EEPROM emulators to remap their CA18/SR20s straight from their android phones.

 

* corrected spelling of emulator. *

Last Edited: Sun. Jan 26, 2020 - 01:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

this is for an old audi ECU. i have a very extensive knowledge base of it through disassembly of the operating code and i can make it do virtually anything i want it to do thats why i never opted for standalone systems. used to to run VEMS standalone and i can do more with the stock ECU than the VEMS could provide for me. 

anyhow im not really looking to make live changes, just a simple interface that allows BIN files to be uploaded to it instead of opening the ECU every single time. i have moates ostrich chip emulators for live tuning which are a pain because i have to switch between them when i i need to make changes to the opposing chip from the one i was working on, their external devices as well so i have to of them with ribbon cables hanging out of the ECU and than i have to stash the 2 emulators somewhere in the ECU compartment. over all my goal is a solution thats self contained inside the ECU with only a single USB cable that exits out of the front of ECU connector. 

going a little more in depth on the idea this is one of the 2 ideas i had since its a 2 eeprom ECU. one would be that each file for the car would have a header attached that designated which eeprom it belonged to. the internal device would look for this header than strip it off the file and than send it to the flash it needs to be on. this could also be dictated by file size alone as well since one file is 64k and the other 32k. the other idea is to combine both 32k and 64k files together into 1 and send it in that way over USB than the device inside knows what hex address to split the file in half and where to send them to be flashed. look i get it, i know this is no novice thing and i probably shouldnt even be attempting it but thats what i was told with this ECU 8 years ago and its now been modified enough to do basically anything a standalone system can do because the of the persistence of myself and others to keep working on it because we could see the potential in it plus it saves 2000+ dollars using the original ECU vs going to a standalone unit. to be honest i have made 800whp out of this ECU on E85 fuel already and i refuse to quit on it now after its given me that kind of power that others said it was impossible to achieve with it. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK - well - its still an EEPROM emulator you want to make.  Regardless if you are doing it one or two chips at time, doing it to flash or RAM or hooking it via LPT/USB/Bluetooth.

 

So I would look at the freely available projects out there for EEPROM emulators as a starting point.

 

If it was my project I would have a large CPLD being glue logic between the two EEPROM sockets on the ECU and some fast SRAM.  Then have an MCU that runs the show and loads the SRAM from a flash on boot.  Have a Bluetooth serial port to download new files.

 

Break the project down into separate parts like that and it will become a lot less daunting.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

VWnut8392 wrote:
to be honest i have made 800whp out of this ECU on E85 fuel already and i refuse to quit on it now after its given me that kind of power that others said it was impossible to achieve with it. 

 

Let's be brutally honest - You could use a could use a couple of 555 timer ics and achieve the same power. Drivability would be useless. Point being is the ECU doesn't determine the achievable horsepower. If the engine requires X advance and Y pulsewidth for fuel, then any ECU should be able to achieve that.

 

Anyways, what ECU are we talking about? I already knew it was old - the eprom types told me this. probably the 'simplest' way to achieve in circuit flashing is to modify the original code to do this. This saves on a lot of external hardware to switch the flash/eeprom chip between the main cpu and the cpu that is doing the reflash. Then your hardware consists of some latches and gates to interface the flash/eeprom chip. Then to do updates via usb - does the main cpu have a serial port? If not, interfacing auart chip should be pretty simple. Then a usb->serial chip completes the solution.

 

Another possibility that comes to mind is to use something like a Cypress PSOC5 device that has some programmable logic that would allow you to create a slave bus interface and use this chip as a smart usb->serial interface.

 

Something a bit left field is to emulate the original cpu - without knowing the exact ECU you're talking about, I'd guess it is either Siemens or Bosch, so it is pretty likely it is using a processor with a 8051 core. There's a number of modern, cheap microcontrollers that could emulate the original processor so you get USB and flash as part of the deal. Since you have detailed knowledge of the code, this makes the task easier - you know exactly what features are being used. I've done a couple of products this way. Once you have the emulation, you can then migrate the emulated code across to native code and hopefully gain to ability to extend the functionality. 

 

 

If you've got links to the code and pictures/schematics of the hardware, I might be able to offer more specific advice.