NefMoto

So here's the deal: made a bench flasher, positive lead into pin 3, 21, 62 and negatives into pins 1 and 2. I have a switch that interrupts the negative lead to both the ECU and the VCDS cable (K line is pin 43).

I was trying to read my stock ECU when it stopped responding. Tried my B6 S4 ECU and Nefmoto connected initially, then once I tried to enter boot mode by grounding pin 24 to the power source I was using (booster battery plugged in at steady 13 volts) I lost communication to it as well.


I thought maybe it had to do with the way I had wired my bench flasher (I didn't interrupt the ground to the dongle and I thought that the ECU was getting a full 12V whenever I hit the interrupt switch (to simulate the ignition)). So I re-did it so that all the grounds were wired into the same interrupt switch. In other words, there should be no way for the circuits to get power to them outside of what the ECU allows unless I ground directly from the power source.

Well, I got a replacement today, I verified that it worked by connecting with Nefmoto flasher and it connected. Then, tried to do a read on the 95040 so I could re-adapt the immo to the cluster. Grounded pin 24 to put it in bootmode and NOTHING, no commumication with the ECU. The exact same thing happened with my S4 ECU as well.

I don't F*UCKING GET IT!!!!!!!!!!!!!!!!!!!!! What did I do wrong???

Has anyone else had this happen?

Does anyone know if there is a way to recover the ECU?

PS: in all 3 instances, when I hook the ECU into the car and try to start it, all it will do is turn over. As well, the cooling fan comes on for some reason.

Honestly, I don't ask for help that often but I'm at the end of my rope as this car is my driver and now I'm waiting another week on my next ECU.... FML

Can You describe in detail the way You get the ecu to bootmode.

Before doing any bench flashing, make sure VCDS connects to your ECU with your bench setup. If that does not work, DO NOT GO ANY FURTHER. Period.


BTW Nef does not support bootmode.

http://s4wiki.com/wiki/Tuning#Flashing_utilities

"The Nefmoto Free ECU Flashing Software and an eBay USB VAG KKL cable - The easiest and best supported method. Does not rely on boot mode, but will not flash bricked ECUs because bootmode support is not complete."

You have to use galletto for boot mode.


If VCDS wont connect on the bench to the ECU, don't bother doing this. It's a waste of time.

ground pin 24 -> turn power on -> 5 secounds later remove ground from pin 24

is this what you are doing?

Yes, although my understanding is that you ground pin 24 for 5 seconds and then turn on the power (which is how I've been doing it)

You are grounding the pin inside the ecu on the flash chip right, not on the connetor?

As indicated in the first post, I connected with Nefmoto flashing software and just got it to read the ECU type to make sure it was working. So yes, I verified that it could connect on the bench.

Also, I've been using a VCDS cable with the serial number hex edited to allow me to use Galletto for any boot mode reading.

What's odd though is that every time I go to read an ECU, the data seems to come back corrupted. The .bin file contains the full 1 MB of data, but there are random patches of values that are basically scrambled. I thought that this was just because my ECU has a Unitronic tune on it, however my S4 ECU Galletto bootmode read seemed to come out the same way.  

Finally, I was using Argdub's tool to read the 95040 immo memory.

Yes, you mean on the little 'leg' that comes out of the ROM chip right?

I'm wondering if my power source is what's doing the damage.

I'm using a Stanley 450 amp booster battery. However, I would think that unless you're engaging a starting mode of some sort, it shouldn't be any different that hooking up to a regular car battery, which is what's powering the ECU in the vehicle.

I've just picked up a 1.1 amp smart-trickle charger, would that be a better power source?

No. Just get a 12V 1A or 500mA wall wart.

Those chargers have all sorts of logic inside that moves the voltage around. They also typically need a significant load to act correctly.

If you slip with a battery like that, you will fry the ecu. You might even start a fire. get a 1 amp power supply. These ecus take about 200ma powered up.

I'll give it a try, the one I bought tonight from Canadian Tire was rated at 13.5v output but when I tested it, it was putting out 20V.

I'm also probably going to bite the bullet and just get a SuperVAG K+CAN scanner to get the PIN from the next ECU I have on order. Gonna be about $300 CAD to get it within North America so i can see it before 30-45 days. 

Seriously though, I'm really regretting ever having tried this.....

If you're using a battery charger, have it connected to a battery.  Unloaded you'll see high voltages (like you have).  Has the magic smoke come out of any of the ECU's?

It does sound like you've cooked them with too much voltage though.  It's all a learning curve though, stick at it and you'll get it cracked! :)

Best power supply is PSU in your PC, just find 12V in one of non-connected power connectors, or buy cheap PSU and use it for such purpose.

by using an interuption switch in the negative leads your not simulating ignition at all.

put it between the ignition 12v wire,.

so I built a new bench flasher and a new power source.

it's a 12V circuit tester (adjusted to put out exactly 13V), 5amp, nice and stable DC

 found another junkyard ecu to experiment on and still, it bricked itself as soon as I tried to put it into boot mode...

So I saw this on another forum and I just wanted a sanity check.

Can anyone explain how this file is used as i know someone who needs to put a new ecu in his car after trying to write in boot mode and putting 12v to the boot pin instead of ground.

when you're putting the ECU into bootmode, you're supposed to touch a ground wire from the 12v power source to pin 24 (the second pin from the left) on the EEPROM.

Also, I have my bench flasher set up to deliver power to pins 3, 21 and 62 correct, not just pin 3?

I had a look at the b5 bench thread: http://nefariousmotorsports.com/forum/index.php?topic=417.0

And the 1.8t bench thread: http://nefariousmotorsports.com/forum/index.php?topic=6324.0

Neither mention powering up pin 21. The 1.8t does need pin 121 powering up..

Given its bricking when you bootmode it, this might not be the issue - why don't you post a photo of your ECU board and highlight the pin you are earthing?

It's really damn obvious what is going on.

He is interrupting GROUND instead of 12V.
So the whole ECU has 12V on it the entire time.

After that he touches pin 24 to the ground. This pin becomes the only ground point inside the ECU at that point.
Now the ECU tries to power up from that ground and obviously fries the MCU and probably the flash with it. I'm sure as hell the internal MCU contacts are not 200ma rated...

Basic electronics class would not go amiss for a lot of you on here.

Granted, that is a fairly compelling argument :)

Never occurred to me that someone would do this. Not in a million years.

Seems plausible. Although it depends where you ground the pin24. The way I do it, I have a gatorclip with a piece of wire. Gatorclip end goes to the ecu board edge where it has a nice shiny ground strip going all around the board and the other end I just stick to the pin. That way the only ground connection will always just be between the pin and board ground.

So if that is how OP has it, then the problem is someplace else. If however OP has grounded the pin24 to somewhere before the ON/OFF switch on the negative lead to the whole flash rig, that would result in exactly what prj explained before.

Perhaps try reading the first post?

This guy fucked up two really basic principles (interrupting ground, grounding pin 24 to the power supply directly and not the ECU board). Now he is paying for it (literally).

You're right, I missed that part.

What's wrong with grounding to the power supply, rather than the board?  Surely it's the same ground?

Wer lesen kann, ist klar im Vorteil.

Not if you disconnect the ground from the rest of the ECU ...

I'm referring to this photo which indicates that pin 21 should be wired in (http://i379.photobucket.com/albums/oo238/tlillo1/VAG_ME7.x_zpsavf8rsoe.jpg) (http://s379.photobucket.com/user/tlillo1/media/VAG_ME7.x_zpsavf8rsoe.jpg.html)

Hey buddy, I'm gonna give you a pass on this one, but tone down the language next time got it.....

I'm asking for some help with an issue and I don't need any attitude. If you don't want to act civil, then please post elsewhere.

Now, if I understand correctly from your post and the other posts, what I need to do is power up the board and then run a clip from the side of the board to the boot pin to give it 12V?

What I don't get is that if I interrupt the positive lead coming into the ECU and try to ground from the side of the board, where is the positive charge to complete the circuit and give me the 12V?

Unfortunately, while there are quite a few text explanations on how to do this, there aren't many physical pictures of an entire stripped down bench flasher reference when I built my flasher.

That last post doesn't cover where You are grounding pin24. That's what this is all about. If You ground it straight to the power source, You are trying to ground all the power the ecu is getting through that small pin24 lead when the switch is open.

Secondly, You can (and should) use the power switch on the positive +12V lead. I'm not sure how other people do it but I do it like this:

1. Everything connected, power switch on the +12V wire coming to bench harness off
2. Ground pin24 to ecu board edge
3. Flick power switch on
4. Keep pin24 grounded for a second or two
5. Remove pin24 ground wire
6. Get boot-mode

I don't really see why You should have the switch on the negative lead.

OK, thanks for the heads up, I think I know what you're getting at.

I'll try and post a picture of the harness up. I've just been super busy lately and haven't had the time.

I do certainly appreciate the input though, thanks much  :)

PS: last post was edited, as I read what you had said earlier.

I don't care what you need or don't need.
You screwed up, I called you out on it. I'm not gonna sugarcoat it.
You made two mistakes that you would never had made, had you paid attention in primary school.
You then proceeded to make the same exact two mistakes four times in a row.

It is also shocking that this is not immediately apparent to some of the longer standing members upon reading your first post, as really it contains all the information needed to see exactly why you fried four control units.
If you do not have a base to build on, you are going to wreck lots of things. As long as they are your own there is no problem.

Just to clarify, the boot pin DOES NOT GET 12V.

No.

Pin should be momentarily grounded (for a few seconds) while you power up the board.

Look, I'm gonna take the high road here and not turn this thread into a typical forum name calling mess.

However, I will state this for the record: As with all forums, there's a general rule that for every person who takes the time to ask a question, there are X number of people who have the same one.

Often times, people don't ask a question because they are self-conscious that they will attract a response just like the one you gave me.

The end result is that someone else doesn't learn from someone else's experience and the community as a whole suffers.

Now, if you want people on here to see you as someone who would hinder the learning process by discouraging people to post up their issues, then hey, it's up to you.

Alternatively, you can choose to use what you know to be seen as a stand-up guy who assists in the learning process.

They both require exactly the same amount of effort and I'm certain that you're more than capable of both options, so why risk being viewed as the former? Just remember, your responses reflect on you and your reputation and you only have one reputation.

Now, with that said, you likely have knowledge that could prove useful to myself and others, so thank you for pointing out my mistake, let's just keep things amicable from here on out, deal?

Sorry, that's what I meant. Not that I would keep it grounded.

It's just the way prj is.  Hang around here long enough and you'll learn it's just the way he speaks. 

He knows these systems like the back of his hand, and I guess having people screw up basic things annoys him, after its repeated time and time again.  Crack on though, you'll be close. 

Just remember the ground pin is from ground, not +12V.  Just paranoid you weren't sure.

All good  :) I've had more than a few forum encounters where I butted heads with someone at first and they went on to be a great resource.

I only get really cranky when the person commenting is completely ignorant and I agree that prj seems to know his stuff which is why I wanted to keep it diplomatic. So water under the bridge for me at this point.

While I can grasp the programming end of it quite readily, for some reason basic dummy level electric stuff still eludes me :p

So just to get something clear here, (and bear in mind I need this explained in dummy speak lol) what exactly does grounding pin 24 to the side of the board do?

My understanding is that in order to enter bootmode, that pin needs a momentary 12v signal going through it.

Now, if I run a wire from the side of the board to pin 24 (i.e. a ground), how is that providing a 12V signal to the pin? Or is grounding to the outside of the board doing something else entirely?

Then a moment later you say


ONE MORE TIME GROUND IS NOT 12V!

Geez.

Anyway. If you want details you need a ton more learnin' about digital electronics.

The cpu samples the pin (which is internally pulled high with resistor) on boot. If it is high (usually 5v) the cpu will boot as normal. Normally this pin is a signal pin, which means the flash chip can pull the signal low (via internal pull down) or leave it floating (for the pullup to take it to 5v).

If the CPU samples it as low (0v) it goes into bootmode, but that requires an EXTERNAL pulldown to overcome the internal pullup already on that pin. If the pin is still low after the CPU is booted, bad things will happen, the CPU will not be able to communicate with the flash chip, as now that signal pin is stuck at 0v.

If you put 12v on that pin, you're gonna kill something. If somebody tells you to ground a pin, do not attach it to 12v. I'm still trying to figure out where you got this idea from. In fact, do not put ANY signal pin to 12V, they are usually TTL (5V or 3.3V max).

If you don't know what a pullup or a pulldown is, stop reading, I really can't deal with explaining digital design at this point. Go take a class.


It isn't.

Thanks nyet for that explanation, I've never bothered to find out what boot-mode actually is on that level.

For the dummy answer, think of a DC light bulb, like a normal brake light bulb in a car for example. You have to provide +12V to other lead and - (commonly known as ground) to the other lead. When both sides are connected, the voltage differential through positive and negative battery poles tries to balance out, electrons go for a swim and current passes through the bulb filament and it lights up. Every time electrons move around in a closed cirquit, their internal frictions on atom level produces heat. The bulb needs a certain amount of amperage to work and provides just the right amount of resistance to the cirquit so that most of that heat is radiated from the bulb and it doesn't burn through the wires and connectors etc. Now pretty much all DC components work with the same principle. Easy so far, right?

No if you would leave the bulb out of the middle and touch +12V and ground together, you get a short cirquit, which means you'll immediately try to balance the car's battery +12V and ground voltage differential through that little point. You'll get sparks and blow a fuse (heat through too much amperage through the fuse). If you didn't have fuse on the wire, You'd burn something else, usually a wire would heat up so much that it melts through its insulation, maybe then the bare hot copper wire is touching something like a floor mat or a seat cushion and sets that on fire.

This is basically what you are doing if you introduce +12V to somewhere it shouldn't go. Something will act as a fuse and burn as long as there is a connection, especially unwanted if that something happens to be an internal ecu component.

This was written from a laymans point. I've never studied electronics after basic classes in college. Couple of hours reading through wikipedia will sort You out.

I think the whole reason of you trashing 3 ECU's is because you've been connecting 12V to the boot pin, and not ground.

Also, you removed ground from the circuit (which you shouldn't) and then grounded the pin (as you should).  The resultant is all the current flows through the boot pin, killing the ECU.

It's just the order you've got it wrong.  It's written out in a few posts above, just do that and you'll get it.

Then, get your understanding written up perfectly, so that anyone can understand it, and post it here.  Get nyet to put it on the Wiki for understanding, and bootmode is a little weak just now.

Adam, Hopsis, and especially Neyt, thank you very much for the well thought out responses.

Nyet, I re-read your explanation and NOW I've got a rough idea of what you're trying to do to put the ECU into bootmode.

Also, as Hopsis said, I've never seen that explanation anywhere else on this site or otherwise either

I've found some reference materials on circuit design that I'm going to plow through in the next bit, I'll report back when I've covered some background reading.

Thanks

Also, in case it wasn't obvious, the "pin 24" we are referring to is ON the board - the flash chip.

Not pin24 on the harness connector (or obdii connector)

https://www.youtube.com/watch?v=kTcRRaXV-fg

 ;D

So now that I have a day off I've been doing some homework.

I had a look at the processor type and searched out the datasheets for the AMD AM29F800BB series EEPROM and  found this online. http://www.datasheet.hk/view_download.php?id=1730503&file=0366\am29f800bb-120ee_3262036.pdf

NOTE there was a supplementary publication added with respect to unprotecting and writing data sections http://www.spansion.com/Support/Datasheets/Am29F800B_prog.pdf

NOTE, as Nyet posted, PIN 44 HAS NOTHING TO DO WITH BOOTMODE. I'm just leaving this up in case someone finds a use for the info.

The Am29F800B is an 8 Mbit, 5.0 volt-only Flash memory organized as 1,048,576 bytes or 524,288 words, designed to be programmed in-system with the standard system 5.0 volt VCC supply.

PIN LAYOUT AND CONFIGURATION
(http://i379.photobucket.com/albums/oo238/tlillo1/800BB20chip_zpsrumxzc12.jpg) (http://s379.photobucket.com/user/tlillo1/media/800BB20chip_zpsrumxzc12.jpg.html)

Pin layout cont...
(http://i379.photobucket.com/albums/oo238/tlillo1/800BB20pin20configuration_zpsfjwclmi1.jpg) (http://s379.photobucket.com/user/tlillo1/media/800BB20pin20configuration_zpsfjwclmi1.jpg.html)

DEVICE PROGRAMMING
Device programming occurs by executing the program command sequence. This initiates the Embedded Program algorithm—an internal algorithm that automatically
times the program pulse widths and verifies proper cell margin.

DEVICE ERASURE
Device erasure occurs by executing the erase command sequence. This initiates the Embedded Erase algorithm—an internal algorithm that automatically
preprograms the array (if it is not already programmed) before executing the erase operation. After a program or erase cycle has been completed, the device is ready to read array data or accept another command.

DATA PROTECTION MEASURES
Hardware data protection measures include a low VCC detector that automatically inhibits write operations during power transitions

READING ARRAY DATA
To read array data from the outputs, the system must drive the CE# and OE# pins to VIL. CE# is the power control and selects the device. OE# is the output control
and gates array data to the output pins. WE# should remain at VIH.

WRITING COMMAND SEQUENCE
To write a command or command sequence (which includes programming data to the device and erasing sectors of memory), the system must drive WE# and CE# to VIL, and OE# to VIH.

HARDWARE RESET PIN
The hardware RESET# pin terminates any operation in progress and resets the internal state machine to reading array data. The RESET# pin may be tied to the system reset circuitry. A system reset would thus also reset the device, enabling the system microprocessor to read the boot-up firmware from the Flash memory.

The RESET# pin provides a hardware method of resetting the device to reading array data. When the system drives the RESET# pin low for at least a period of tRP, the device immediately terminates any operation in progress, tristates all data output pins, and ignores all read/write attempts for the duration of the RESET# pulse. The device also resets the internal state machine to reading array data. The operation that was interrupted should be reinitiated once the device is ready to accept another command sequence, to ensure data integrity.

Current is reduced for the duration of the RESET# pulse. When RESET# is held at VIL, the device enters the TTL standby mode; if RESET# is held at VSS ± 0.5 V, the device enters the CMOS standby mode.

The RESET# pin may be tied to the system reset circuitry. A system reset would thus also reset the Flash memory, enabling the system to read the boot-up firmware
from the Flash memory.

If RESET# is asserted during a program or erase operation, the RY/BY# pin remains a “0” (busy) until the internal reset operation is complete, which requires a time of tREADY (during Embedded Algorithms). The system can thus monitor RY/BY# to determine whether the reset operation is complete. If RESET# is asserted when a program or erase operation is not executing (RY/BY# pin is “1”), the reset operation is completed within a time of tREADY (not during Embedded Algorithms). The system can read data tRH after the RESET# pin returns to VIH.

When the system drives the RESET# pin low for at least a period of tRP, the device immediately terminates any operation in progress, tristates all data output pins, and ignores all read/write attempts for the duration of the RESET# pulse.

SECTOR PROTECTION/UNPROTECTION
The hardware sector protection feature disables both program and erase operations in any sector. The hardware sector unprotection feature re-enables both
program and erase operations in previously protected sectors.

Sector protection/unprotection must be implemented using programming equipment. The procedure requires a high voltage (VID) on address pin A9 and the control pins.

TEMPORARY SECTOR UNPROTECT
This feature allows temporary unprotection of previously protected sectors to change data in-system. The Sector Unprotect mode is activated by setting the RESET# pin to VID. During this mode, formerly protected sectors can be programmed or erased by selecting the sector addresses. Once VID is removed from the RESET# pin, all the previously protected sectors are protected again. Figure 1 shows the algorithm, and the Temporary Sector Unprotect diagram shows the timing waveforms, for this feature.

HARDWARE DATA PROTECTION
The command sequence requirement of unlock cycles for programming or erasing provides data protection against inadvertent writes (refer to the Command Definitions table).

In addition, the following hardware data protection measures prevent accidental erasure or programming, which might otherwise be caused by spurious system level signals during VCC power-up and power-down transitions, or from system noise.

Low VCC Write Inhibit
When VCC is less than VLKO, the device does not accept any write cycles. This protects data during VCC power-up and power-down. The command register and all internal program/erase circuits are disabled, and the device resets. Subsequent writes are ignored until VCC is greater than VLKO. The system must provide the proper signals to the control pins to prevent unintentional writes when VCC is greater than VLKO.

Write Pulse “Glitch” Protection
Noise pulses of less than 5 ns (typical) on OE#, CE# or WE# do not initiate a write cycle.

Logical Inhibit
Write cycles are inhibited by holding any one of OE# = VIL, CE# = VIH or WE# = VIH. To initiate a write cycle, CE# and WE# must be a logical zero while OE# is a logical one.

Power-Up Write Inhibit
If WE# = CE# = VIL and OE# = VIH during power up, the device does not accept commands on the rising edge of WE#. The internal state machine is automatically reset to reading array data on power-up.

The flash datasheet has nothing to do with boot mode.

The purpose to grounding DQ4 is to notify the CPU to start in boot mode.

The flash never sees it during boot.

If you want to know how bootmode works, consult the CPU datasheet.

No.


No.



Has nothing to do with boot mode.



No. Pin 44 has nothing to do with boot mode.

Well, glad I didn't waste 3 hours of my life making that post...  :P

No biggie though, I always end up learning something from these kind of exercises.

I'll retract my comments so as not to confuse matters.

Not sure if you want me to pull the entire post lest anyone gets confused, let me know either way.

Cheers

Edited out commentary and just left summary

Now, do you happen to know of any links to the CPU datasheet?

EDIT: nevermind, found it in the S4wiki

You're looking for page 16

"The PORT0 configuration is treated as if it were a hardware reset. In particular, the
bootstrap loader may be activated when P0L.4 is low."

Flash pin DQ4 is connected to CPU pin P0L.4 (port 0, bit 4).

I feel this thread is getting way too complicated.

1. Everything connected, power switch on the +12V wire coming to bench harness in off position
2. Ground pin24 to ecu board edge
3. Flick power switch on
4. Keep pin24 grounded for a second or two
5. Remove pin24 ground wire
6. Get boot-mode

I think the point here is that the original poster wants the why, not just the instructions how.

I think that is a good thing.

Thanks Nyet  :) You're correct.

While I definitely appreciate all the responses to my immediate concerns about how to re-flash on the bench, I feel that it's way more useful to learn the ins and outs of an area rather than just expecting others to spoon feed me answers every time something goes wrong.

I also get a real sense of satisfaction if I can contribute back to any community that I'm a part of. Unfortunately I'm in a position where I'm starting from scratch here, but thanks to people like yourself, NOTORIOUS VR, etc... at least I have an opportunity to actually learn some of the how's and why's of tuning and electronics.

I'm also mindful of the fact that you and the other mods/admins take a lot of time to make sure that this site doesn't get polluted with a bunch of misinformation and speculation. I'm also mindful that it takes time out of your schedule to read through everyone's posts to screen that info, so I'll try not to flail out too hard (well any harder than I've already been flailing out lol.  ;) )

On a bit of a side note, I found it incredibly frustrating just how little GOOD and RELIABLE information there has been about Bosch tuning until this forum started up. So I'm hoping that by getting myself up to speed on this stuff I can make my own contributions back to this forum.

So at the risk of sounding like a broken record, big up to everyone here on this forum who has and will take the time to educate myself and others. *thumb up*

PS: To Nyet and others, I can't remember if I told you that my alter ego on Audizine is Zimbuthemonkey. If not then, well... Hiya ;) 

So, update time:

I managed to exchange the ME7.1 ECU I fried for another ME7.5 ECU I pulled out of a 2004 A4

Using the method explained (grounding to the strip on the side of the ECU) I managed to get the ECU into bootmode successfuly.

Using an Ebay VAG-COM cable (and my genuine ROSSTECH one) I confirmed that ECU was working by connecting to it with VAG-COM. It connected fine.

I should add that I've been using the Galletto software from this site, re-coded with the correct serial number for any Galletto related flashing. I also use Argdub's software for any immobilizer related flashing and reading

Then, I put the ECU into bootmode and used Galletto to 1) get a read of the EEPROM, 2) to get a read of the immo coding and 3) and to flash my stock 559E file to the new ECU.
 
It read and re-flashed the EEPROM fine as well as reading and flashing an immo off 95040 file.

The issue that concerns me is that, much like all the other ECU's. I couldn't connect back to it with VAG-COM or the Nefmoto flashing software after I did the bootmode related stuff.

I should also note that my cable has been set to work in 'dumb mode', just to rule that out.

Any thoughts on this? Like I said, it reads fine in bootmode, but it won't connect otherwise. I'm hoping it's just a byproduct of flashing an ME7.1.1 file to an ME7.5 ECU and something that I did to wreck the ECU,

I want to get this resolved before I get my replacement ECU on Monday. Honestly, after weeks of dicking around with this, I just want my bloody car back :p

PS: this seems to be a common thread between all the ECU's I've been experimenting on. Is there any possibility that this is just a 1) communication/flashing issue or 2) immobilizer issue and that the hardware on my other ECU's may be recoverable?

You can't just swap different ecus, they aren't compatible. Hell, You can flash a picture of Your neighbours dog to the ecu in bootmode but it won't communicate with the car or read with Nefmoto or VCDS afterwards.

This is never possible. Even ECUs of the same ME version aren't always cross flashable.

Just to clarify, I wasn't intending to use the ME 7.5 ECU in my car lol. 

It was the only other good ME7x ECU that I could exchange with the one I bricked (Pick and pull doesn't give refunds, just exchange for the same part).

This purpose of this exercise was simply to confirm that my flashing process isn't frying anything.

Given that I can still access the ECU multiple times over, I'll take that as a good start.


However, back to my other question. Interestingly enough, I can still read the EEPROM contents on my original A4 and S4 ECU's as well as flashing the 95040 contents.

What I cannot seem to do is write to them. Again, I'm going to assume that I must have fried something downstream of the EEPROM which has damaged ECU's abiliity to function. That said, I just want to rule out a memory related issue (i.e. immobilizer and the like).

Would I be correct in my assumption that even though the ECU's can be read, that I have probably damaged the CPU with my previous boot mode attempts?

I have a big box of dead ecus from bad boot attempts that still will run in bootmode, read and write. Just no comms.

I should also add that I have some hardware arriving tommorrow: 1) Galletto V54 clone 2) VAG-ECU tool that should give OBD access to the 95040 memory and EEPROM contents 3) VAG-TACHO and 4) blank transponder chips (just in case I ever have to re-program any keys).

So hopefully that should allow me to do an in-car re-programming of the new 559E ECU that will arrive on Monday without having to go through the whole bench flash / bootmode routine :p

Lol, well that makes me feel a little better knowing that I'm not the only one around here who's wrecked ECU's. Thanks ddillenger ;)

Another question I had that really didn't a confirmed answer was this: Which pins require 12V to the harness?

Based on this picture I got on this site, I ran power to pins 3, 21 and 62

(http://i379.photobucket.com/albums/oo238/tlillo1/VAG_ME7.x_zpsavf8rsoe.jpg) (http://s379.photobucket.com/user/tlillo1/media/VAG_ME7.x_zpsavf8rsoe.jpg.html)

However one of the early responses in this thread suggested that the way I had it set up was incorrect. 

So just to be clear, which pins require power?

To be clear, they came to me like that-haha. I have only destroyed a small handful of ecus, and most were intentional :o

All of those pins need power, and 121 on the smaller connector for OBD writing mk4 ME7.5's on the bench.

Well, consistent with the rest of my life, I tend to learn my lessons the hard way lol.

Fortunately, whenever I do, I end up taking every opportunity to learn what I did wrong along the way, so it works out better in the end. It's just kind of frustrating to get there sometimes ;)


As well, I want to clear up a few points on getting the immobilizer to work with the new ECU.

Now, I can advise that I've used argdub's tool to read and save my ECU's original 95040 coding

Now, can I just transfer that my stock ECU's 95040 read directly to the new ECU, plug it in and go?

Unfortunately, since my old ECU had a reflash on it, I can't completely clone the new ECU with both the EEPROM read and the 95040 from my old ECU. Only the 95040 read is any good.

With that in mind, will there be some other coding stored elsewhere in the new ECU (i.e. EEPROM contents or otherwise) that would conflict with my old ECU's 95040 coding?

In that case should I use the 'immo off' file that argdub posted?

Now, in argdub's immo off file, when I open it in a hex editor, I see that the VIN number and the cluster coding is represented by a bunch of XXXXXXXXXX in the sidebar (red circle). Am I correct in assuming that I transfer the VIN and cluster info from my original ECU (yellow circle) to those areas? Also, what about the info in the blue areas, does it need to be transferred as well?

Or do I just use the 'immo off' file as-is?
(http://i379.photobucket.com/albums/oo238/tlillo1/60062c60-6147-4100-9622-326de41b5d5d_zpsoyahqgqq.jpg) (http://s379.photobucket.com/user/tlillo1/media/60062c60-6147-4100-9622-326de41b5d5d_zpsoyahqgqq.jpg.html)

Finally, am I correct in assuming that if I do have to insert any new information into any 90540 file that I'll need to make checksum corrections as well (I do recall seeing someone had posted a checksum corrector in the 'understanding the immobilizer' thread)

The other option is, if the hardware I have coming works properly, I may choose to recode the cluster and re-code my key with a new transponder blank to make the car work with the new ECU.

That said, my read through some of the threads here indicates that trying to re-code clusters carries it's own risk that you can fry something in the cluster and then you're really SOL and ripping out your dash to boot....

My concern with trying to recode the 95040 file is that these later ME7.1.1 ECU's carry additional immo coding in a chip other than the 95040 chip

The other option is, can I just

1) recode the original ECU 95040 read to 'immo off' (by changing the circled bytes from 01 (IMMO ON) to 02 (IMMO OFF), and flash it to the replacement ECU or...

2) recode the replacement ECU 95040 to 'immo off' and then re-flash that back onto the replacement ECU

Again, in both instances I'm assuming that checksums will need to be re-done correct?

(http://i379.photobucket.com/albums/oo238/tlillo1/79e18996-5c56-42e9-9efe-30176a5ba424_zpsyvlttf3n.jpg) (http://s379.photobucket.com/user/tlillo1/media/79e18996-5c56-42e9-9efe-30176a5ba424_zpsyvlttf3n.jpg.html)

You can easily burn out ecu components if you flash the wrong file. Boot mode working means absolutely nothing.

You must checksum the file after making the changes to the eeprom. Subtract one from 0x1E and 0x2E when adding one to 0x12 and 0x22.

Hmm, this is the first I've heard of an improper file itself burning out ECU components, please elaborate.

Also, any input with respect to the immo question above? I'd appreciate any feedback from either yourself or the other senior members on the matter.

While the immo thread that I referenced is immensely helpful, there are some unanswered portions for me I want to clearly document in case anyone has similar questions.

And your extensive experience with digital electronics design is?

So just to be sure, change from the values on the left to those on the right?
(http://i379.photobucket.com/albums/oo238/tlillo1/9d93e5de-edd4-405f-85f0-37624ff0a0d5_zpssfr4wosf.jpg) (http://s379.photobucket.com/user/tlillo1/media/9d93e5de-edd4-405f-85f0-37624ff0a0d5_zpssfr4wosf.jpg.html)

Probably about as extensive as your knowledge of criminal law.

Which is why if you were to be self-representing yourself at trial, I would think that it would be exceedingly foolish if you weren't asking questions to someone who does have expertise in that area.

Now, may we dispense with the posturing please? I'm a little confused as to how you took my not having heard of something to mean that I didn't think that was the case. It was an honest question, one that I was curious to hear your answer to. Quite frankly I felt that it would be rather informative/interesting.

As indicated, I appreciate your assistance and I've made it quite obvious that I respect what know about the field. I've also treated you with quite a bit of respect. However, I also expect that you're secure enough in your knowledge that you won't get offended at any hint of someone questioning it (which as I indicated earlier, was totally inadvertent).

In any event, I don't wish to turn this thread into a p*ssing contest, so let's both of us continue to act civil and respectful from here on in.

Thank you

"First I've heard" implies long term experience. Why not start with "I don't know anything about EE"?

Anyway: set up an I/O wrong and you can easily end up having a sensitive device sink too much current. I've popped the top of an FPGA with a single bit error. It literally exploded.

Just one of many, many, many ways things can go wrong.

Ahhh, the joys/dangers of communicating via text, just ask me how well it worked when I was dating lololol ;P


Cool trick being able to blow up circuit boards with a misplaced bit though  ;)

That's a seconds golden piece of information I've gotten from this thread already. Never even occurred to me that there could be fatal hardware errors by flashing a wrong file. Maybe I've just been lucky so far as I've done my share of mistakes like flashing ME7.1.1 file to a ME7.1 ecu (tired, not concentrating, picked a wrong file from folder). I immediately figured what was wrong when car didn't start but never thought I could have bricked the ecu.

I've learnt more from reading about other peoples problems (exactly like this thread) than just reading how something SHOULD have been done. All the information is there but this way burns a better lasting memory imprint than browsing through pages of instructions and not knowing what does what. This might sound bad, but for the rest of us beginners it's a good thing that someone is stupid/brave enough to make these mistakes and definitely brave enough to admit them and ask afterwards. This is intended as a compliment, not an insult  ;)

This is correct.

Perfect, thanks much

I also had a little helping package arrive today  ;D

I ordered myself a

-VAG-ECU tool dongle,  
-Galletto V54, VAG
-VAG-TACHO USB 5.0
10 x Audi ID 48 Glass transponder chip
10 x for VW TP23 ID 48 transponder chip

So here's hoping I can now do everything I need right through the OBD port.


By the looks of it, I should be able to plug in the new ECU, set the immo to OFF via the OBD2 port and off to the races



PS: if anyone needs to buy a transponder chip, let me know. I wanted them as a back-up in case I needed to make some new keys. Problem is I needed to order them in batches of 10.

I'm sure I can offer a price that would ne better than the $100-300 that the dealer wants for the key fob that comes attached to the new transponder :p

yay, china.

PFFT

Between the two of us we have subsidized the shit out of the chinese economy.

Yessir  ;D

It's crazy what you can just order up nowadays. Hell, I even got the stuff shipped to my door from Hong Kong in 3 days and $50 shipping.

Lol, what's holding up progress are the ECU's I ordered over 2 weeks ago from the States.

me and you both have also paid a large stack of C notes to a few select brit's and european's as well.

Well, I finally got ECU's delivered and both are now happy in their new home  ;D ;D ;D

k0mpressed and ddillenger: I can see why the two of you have subsidised half the Chinese economy though.

The EEPROM reading tool that I got didn't really work worth a damn. First, it only reads the 95040 EEPROM, not the 800BB flash EEPROM memory as the site's engrish description led me to believe. Second, it only seems to read/write when it wants to and when it does, it buggers up the flash half the time. I played around with the COM port baud rates and it seemed to help some, but I couldn't seem to get a clean write. Good thing Argdub's 90540 came to the rescue. From there, Tony's flashing software is doing the rest.

So hats off to all those on this site who have taken the time to make software that works, you guys rock!!!  ;D

Yay! :) Well done man!

Hate to revive an old and very colorful thread, but looking to get a couple things done on my B6 A4. I've read this thread (twice) and the immo thread by ddillenger amongst a few others over the years, but those two most recent. My end goal is something most of you probably could do in about 2 minutes flat, but it'll take some learning for me, which is why I'm posting. I want to get a spare ECU for my 1.8 and basically clone mine leaving the immo on as it shouldn't affect anything. I know Argdub's thread should have more info on that. I also, if I can get my hands on one would like to get a second hand stage 1+ tuned ECU and use it in my car, as I have all the supporting hardware already. But from my research, I'll need to turn the immo off, otherwise the tune will wipe itself, when I marry it with my car.

First things first, the KISS way was quoted here for bench testing, which I have no doubt I can do correctly.


1. Everything connected, power switch on the +12V wire coming to bench harness in off position
2. Ground pin24 to ecu board edge
3. Flick power switch on
4. Keep pin24 grounded for a second or two
5. Remove pin24 ground wire
6. Get boot-mode


From here, I think argdubs thread about 95040 EEPROM programmer (http://nefariousmotorsports.com/forum/index.php?topic=1168.0title= (http://nefariousmotorsports.com/forum/index.php?topic=1168.0title=) should steer me in the direction I need to go to get the info out and write back to it with the help of a hex editor (which I have used before to get my SKC using vag commander).

I'm looking for confirmation that my rough path of thinking is in line with what you people would do in this scenario. If not, please let me know what I should be searching/looking up instead.

Heh... Me too.. Was it a Xilinx?

Where are you going to get this from?

No you don't.  You never have to turn the immo off unless you're swapping the block into a motor without the right cluster combo.  The only reason the immo will kick in is if the flash file doesn't match the 95040, which means you're flashing random files on the ECU which also isn't good.

If you want to duplicate them, use ArgDubs tool to read the 95040 from your current ECU; NefFlasher to read the chip and then flash the chip and 95040 in bootmode onto your new ECU.

Tune your current ECU, keep the new one as a spare.