Pages: [1]
Author Topic: terminology - boot mode vs over OBD vs in-car vs desolder etc  (Read 9767 times)
elRey
Hero Member
*****

Karma: +31/-1
Offline Offline

Posts: 565


« on: January 19, 2011, 12:04:17 PM »

I would like a little clarification on the difference between some of the terms used around flashing ECUs.

i.e. When some mention "over OBD" I first thought that meant in-car flashing only. However, I believe it also applies to boot mode.

I also would like to get a little more info on the process that's happening in each instance.
i.e. in-car flashing, I believe, utilizes flash functions in the code you're writing over, right?
vs boot mode utilizes the processor on the board to write the to the eprom?
And how does that differ from desoldering, using a programmer, and resoldering? <- what's that call?

Thanks,
Rey
« Last Edit: January 19, 2011, 12:49:41 PM by elRey » Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +130/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #1 on: January 19, 2011, 12:37:15 PM »

Over OBD means using the KWP1281 or KWP2000 protocols supported by the ME7 firmware. This is how the dealership flashes the car and it requires the ECU to have a working version of the ME7 firmware. Since this uses the protocols in the ME7 firmware to read the flash memory, it is possible to update the protocols to disable reading.

Boot mode means using the boot strap loader built into the C166/C167 processor. This uses the debugging features supported by the processor to load a program into RAM to allow you to read/write the flash memory. This does not require the ECU to have a working version of the ME7 firmware on it. Since the boot strap loader is loaded by you into RAM, you can bypass any software protection in place to prevent reading the flash memory contents.
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
Jason
Hero Member
*****

Karma: +38/-0
Offline Offline

Posts: 500


Breaks everything!


« Reply #2 on: January 19, 2011, 01:22:34 PM »

To answer your question about standalone flashing of the chip, if you remove the flash from the PCB, you can read/write it using something like this:

http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=4282
http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=3149

This hardware device reads/writes to the chip in essentially the same way the processor does - using the electronic interface of the chip and sending the appropriate electronic signals.

Note that you can't use a willem programmer read flash contents that are behind an encryption board (note: you can, but you will just be reading the ENCRYPTED contents of the flash), because the encryption chip waits to detect the ECU booting, before it "unlocks" and starts decrypting the contents of the flash.  This "decryption/encryption" process is kind of a misnomer from what I understand, because in most implementations, the encryption chip sits between just jumbles the contents of the flash around - so the data meant to be stored at a particular address is actually intercepted by the encryption chip, and then the chip stores it in a completely different location on the actual flash chip.  When you request to read a location, the encryption chip knows where the byte is that you're looking for, and then reads the alternate location on the flash chip, and sends the data back - the CPU is non the wiser.

Note I am not condoning stealing somebody else's work - but there are some times you many need/want to bypass this "protection" to fix a tune you rightfully own - or - if you're like me, you don't like the idea of lots of mechanical interfaces that could potentially fail over time with corrosion/vibration, etc.  In most cases boot mode can be used to circumvent this "protection".  I have also seen one instance where NefMoto could read it, probably because the tuner didn't think that reading over OBD would be a threat in the future, or didn't know how to disable the function used for reading over KWP. 

I then removed the eeprom from the encryption board, desoldered the encryption board, desoldered the eeprom from the encryption board, soldered it in place of the board back on the ECU's PCB, made the necessary changes to the rom, and then used boot mode to write the decrypted/modified flash to the freshly soldered eeprom that was encrypted. The result was a configuration I think is more reliable, and the flash could be read/changed in the future without any hassle.

In closing, each tool is extremely useful and you will probably find that NefMoto is invaluable along with Galletto.  You probably don't need an eeprom programmer.

An easy way to differentiate between the functions/use can be broken down like this:

NefMoto:

   Pros:
   *Fast flashing by only writing CHANGED data.
   *Fast reading.
   *Convenient because the ECU stays in the car.
   *Tony is awesome and provides awesome support.
   *Future functionality like checksums will be great.

   Cons:
   *Sometimes tuners disable the read function required to read the ECU
   *No recovery if you have an ECU with a flash that won't boot


Galletto:

   Pros:
   *Can recover from a bad flash
   *Can bypass some protection mechanisms

   Cons:
   *Requires physical access to the ECU's PCB to short the boot pin to ground.  This can suck if your ECU is buried below tons of trim pieces.
   *Slow flashing because the ENTIRE flash is written.


Eeprom Programmer:

   Pros:
   *Absolute low-level recovery from a bad flash
   *Eeprom can be tested/zeroed out
   *Can be used with an adapter to read the Serial eeprom (separate from the program eeprom, where DTC's and other parameters are stored separate from the program flash)
   
   Cons:
   *Requires desoldering/resoldering the eeprom from the PCB, which has a risk of damaging the PCB by lifting pads, etc.
   *Even if socketed, you run the risk of PCB damage, or physical connections that come loose over time.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.017 seconds with 16 queries. (Pretty URLs adds 0s, 0q)