Anybody interested in how to dump 93cXX with a Raspberry Pi

[frearks]

Hi all,

First post to the board - not wanting to be someone to just show up and take take take, I have spent the last week trying to work out how to dump the EEPROM from the KESSY module in my Touareg.

I ended up managing to do this using the SPI interface, and a small, poorly written Python script. If anybody is interested, I'd be happy to share the code that I used, and how it works.

In the end, I wired the Pi directly to the chip, without removing it from the board. All I needed was some small wires and a soldering iron.

[Youneselm]

Always good to know!!!;-)

[wormland]

I am also intersted :-)

[Code Breaker]

Sounds good, I'd like to know more

[frearks]

It's taken a while to get my Pi back out. I was cleaning up my play area today and remembered I said I would share. Well here you are.

Caveats:
1) I don't have a pinout/schematic handy for you, it is 5 wires to connect, including power. I just soldered them onto the IC and left it in circuit. What to connect where was pretty self explanatory.
2) What is provided comes without any warranty, or technical support. It is poorly written as I wrote it using a lot of trial and error.
3) If you have a look at the code, you'll see I figured out a hacky way to work around the problem that there is no way within the current "spidev" library to leave the CS high after reading a byte.
4) I didn't bother to fix the data output. You'll need to shift it all a few bits to the left (5 bits from memory) for it to make sense. Open the resulting file in WinHex and start deleting bits at the start of the file, and it will be clear when you have shifted it correctly. This can probably be worked around by bit banging the correct number of clock cycles on the GPIO interface, but I couldn't be bothered going that far.

You need to connect the "CS" pin on the chip (I think it's labelled something different in microwire interface) to the "SPI - 1" not "SPI - 0". Take a look at the code and you'll see that it is configured to open/read "Chip 0", but I have added in some lines earlier (GPIO.xxx) to select "Chip 1" at the start of the routine and deselect it at the end. This allows us to take advantage of the fact that the 93cXX chips will continue returning sequential data as long as a clock signal is generated.

None of this probably makes sense. It worked for me. You need the spidev, time and RPi.GPIO libraries to make this work. Good luck!

#!/usr/bin/python

#93c46 dump routine
import spidev
import time
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(26, GPIO.OUT)
GPIO.output(26, False)


spi = spidev.SpiDev()
spi.open(0,0)


#93c46 chip select is high rather than low
spi.cshigh = True
#Combine the start bit and first bit of the read instruction into one
#to be sent as first byte. Second bit (0) of read instruction will be
#provided along with address to read in second byte
start_read = 0b11
count = 0
addr = 0
f = open("dump.bin", "wb")
#while (count < 128):
GPIO.output(26, True)
while (count < 1):
#shift the address to the left so the dummy 0 bit that comes back is
#part of the address byte we're sending. This saves having to do bit
#twiddling with the response (to ignore the dummy 0).
#       resp = spi.xfer2([start_read, count << 1, 0x0, 0x0])
        resp = spi.xfer2([start_read, count << 3 ], 0, 40000)
#convert the two returned bytes into hex and print them


        print resp
        while (addr < 8193):
#       while (addr < 10):
                resp = spi.xfer2([0x0], 0, 40)
#               ch1 = "%X" % resp[0]
                bin1 = resp[0]
                b = bytearray ( [bin1] )
#               print addr, ":", ch1.zfill(2)
                f.write(b)
                addr = addr + 1
        count = count + 1


GPIO.output(26, False)
f.close()

[XmoDDeR]

Yes nice work can you hit me on skype