Embedded Results AVRUSB Hack

Programming the AT90S8515 to read an 93LC56 EEPROM and interface to an FT245BC USB converter chip

Some time ago a friend, knowing my preferences for AVR microcontrollers, gave me a USB AVR Programming device.
When I got it home I plugged it in and it reported itself as an “Embedded Results AVRISP” but Windows could not find any drivers for it. Indeed all my internet searches only turned up non-working drivers.
I already had plenty of AVR programmers so the device eventually found its way into the spare parts bin.

Recently I was looking for something new to hack and found it there.

Inside the case was a circuit board with an AT90S8515 microcontroller and another module that looked like it was designed to fit in a 28 pin DIP socket. That module had an FTDI FT245BC USB chip and a collection of support components. (It looked very interesting)

Programming the AT90S8515

The first step was to see if I could talk to the AT90S8515. I grabbed a meter and found the connection points for

GND, VCC, RESET, MOSI, MISO and the SCK signals. A few quickly soldered wires and I had connections leading to

a solderless breadboard and from there to my USBASP programmer. It took me a couple of tries using AVRDUDE

to discover that I needed to reduce the SPI clock rate quite a bit before it would be recognized. But eventually success!

During my probing to find the SPI pins I also found the LED was connected to PD5 on the MCU. I was ready to code

a blink program. I paused for a moment before issuing the flash erase command knowing that, once issued, this

device would never again be an Embedded Results AVRUSB.

Once I had the blink routine working I discovered that the LED was actually a dual color (Red/Green) led.

A high level on PD5 turned on green and low turned on red (configuring PD5 as an input turned the LED off).

Next step was to get the UART pins working. Initially the TXD line refused to work without the addition of a 330 ohm

pull-up resistor on it. (I later discovered a connection between it and a pin on PORTC of the MCU)

Having success with the UART I then chose to re-wire the 10 pin connector to match that of my (modified) USBASP

programmer. This gave me a neat connection for programming and serial I/O.

I considered quitting there but I was still intrigued by the FTDI module labeled “UMP2” and “WWW.ASIX.CZ”.

I was surprised to find a pretty good manual for the module. I also got the datasheet for the FT245BC.

(both attached below)

Reading through the latter I discovered the FTDT chip supported a method to use an external EEPROM to store

custom VID & PID and description values for the USB device. It also stated, that if no EEPROM was detected it would

default to the FTDI supplied values. Sure enough, if I disabled the EEPROM chip on the UMP2 module by suppressing

the chips CLK input, the device the reported itself to Windows as an FTDI USP-Serial Converter!

Sadly, for some reason, it reported a PID value of 6005 and the only drivers that I could find were looking for PID

values of 6001, or 6010 and above. Nuts…..

Reading EEPROM Data

Once again I considered quitting but was drawn back in…. What if, I could re-program the EEPROM and make it report the proper VID, PID and description of an FTDI Serial Converter? There was an unpopulated connector on the board

that gave me connections to all 8 bits of PORTA on the MCU as well as VCC and GND so a couple more quickly soldered connections, a download of the Microchip 93LC56 EEPROM datasheet and I was off to code a read/write

program for The EEPROM. That involved a couple of late nights as I had missed the part in the datasheet about the

EWEN command requirement necessary to enable writing to the EEPROM.

I finally had a read of the EEPROM data that clearly showed me the VID(403) and PID(F370) values and well as the text of the device description. As for the rest of the EEPROM data, I had no clue as to what it should actually be.

Old EEPROM Contents (word offsets)

00: 00 00 03 04 70 F3 00 04-80 16 0C 00 00 00 94 0A ....p...........

08: 9E 30 CE 08 0A 03 46 00-54 00 44 00 49 00 30 03 .0....F.T.D.I.0.

10: 45 00 6D 00 62 00 65 00-64 00 64 00 65 00 64 00 E.m.b.e.d.d.e.d.

18: 20 00 52 00 65 00 73 00-75 00 6C 00 74 00 73 00 .R.e.s.u.l.t.s.

20: 20 00 41 00 56 00 52 00-55 00 53 00 42 00 08 03 .A.V.R.U.S.B...

28: 61 00 39 00 37 00 02 03-00 00 00 00 00 00 00 00 a.9.7...........

30: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

38: 00 00 00 00 00 00 00 00-00 00 00 00 01 00 C2 34 ...............4

FTDI supplies a utility to program the EEPROM over USB but it will do nothing if it’s can’t detect a device.

Since I could not find any working drivers I was out of luck there. But some luck came my way when I discovered a user’s guide for a much older version of the utility. It contained a screen print that showed a dump of typical EEPROM data using the default VID & PID values. Note:utility uses byte offsets

I re-wrote my EEPROM dump routines to dump the data in a similar way as the utility screen print showed so I could easily compare the devices original EEPROM contents with the example values.
I saved a copy of the original values and input the ones from the screen shot.
That initially failed with Windows complaining it could not find a device with PID of 60C1.
Changing the “C1” byte to “01” fixed the problem. I don’t know if the screen print data was actually in error or if it was purposely changed to keep folks like me from loading EEPROM data without their utility. I found a few other bytes that were suspiciously different from what I expected and changed them too.

(see screenshot bytes at offset x04, x14, x64 & x74 have 'C' where I expected '0')

NEW EEPROM Contents (word offsets)

00: 00 00 03 04 01 60 00 04-A0 16 08 00 10 01 94 0A .....`..........

08: 9E 2A C8 12 0A 03 46 00-54 00 44 00 49 00 2A 03 .*....F.T.D.I.*.

10: 55 00 53 00 42 00 20 00-53 00 65 00 72 00 69 00 U.S.B. .S.e.r.i.

18: 61 00 6C 00 20 00 43 00-6F 00 6E 00 76 00 65 00 a.l. .C.o.n.v.e.

20: 72 00 74 00 65 00 72 00-12 03 46 00 54 00 42 00 r.t.e.r...F.T.B.

28: 36 00 30 00 57 00 4A 00-55 00 02 03 00 00 00 00 6.0.W.J.U.......

30: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

38: 00 00 00 00 00 00 00 00-00 00 00 00 01 00 8B E9 ................

The device then responded correctly and Windows now loaded the FTDI drivers and it appeared as a new COM port.
After mapping out the signal paths between the FTDI chip and the MCU I started the next project to attempt to send data to it and have it appear on a terminal program connected to my new COM port.
This worked (sort of) since I chose a hex 0x55 (“U”) as my test character.
Whenever I tried to send a byte with an even value (bit 0 = 0) the system would reset itself.
Additionally, when reading from the device, some of the upper bits would only read as zeros.
Some more probing with the multi-meter revealed connections between other components on the board and PORTB which was used as the data I/O port for the FTDI chip. I lifted a couple of components off the board to break those unnecessary connections and cure this problem.
So now I have a handy programmable device with a working USB connection, all in a nice little project box.
I added a header connector to the unpopulated space on the board making VCC, GND and PORTA available as well as an external RESET button.

This could someday make a nice PC – {whatever} interface device via a USB connection.

Links:

AT90S8515_datasheet.pdf AT90S8515 Microcontroller Datasheet

93LC56_datasheet.pdf EEPROM datasheet

FT245BM.pdf FTDI FT245BM datasheet

ump2_en.pdf UMP2 Module users guide