Tweet
Greetings folks,
I have a little info on S702 to share since I am doing a similar project to this with Motronic 1.7 (E30 318iS w/ M42 engine). While it is obviously not exactly a DME or vehicle that people here are concerned with, M2.3.2 and M1.7 do share the same core architecture. I figure that anything learned about S702 on one system will be helpful for people working on the other! Hopefully that is the case, anyway.
First, there are a couple of variants of the PLCC-68 S702 chip out there with different markings, but they all seem to have the same functionality. The most helpful thing I have found so far, other than the M2.3.2 schematic, is vwnut's photo on his Google Drive which shows S702 and its markings (one variant of it anyway). It has the logo for Harris Semiconductor, which Intersil acquired in the late 1990's. There is no information on PN TA13255A available on the web, but the number gives me some clue as to what it is. If anyone here developed with 8051/2/85/86/etc MCU's, they are probably familiar with the 8155 & 8255 peripheral expanders. Both of those were 40 pin devices. The S702 part pinout seems to indicate that it is some combination of the two since it takes both a clock input, as well as 3 address lines (A13-A15), along with all of the stuff common to both of the smaller chips. The "13" in 13255 is, in my estimation, Harris Semi's way to indicate that it was a larger version of the 8255. Whatever the case, it is sort of a black-box which serves a ton of functions. I see that vwnut annotated a copy of the M2.3.2 schematic to have some more info, and S702 is labeled with "30074" and "CC151V1" which are the identical markings to the part in M1.7. It is also branded as being from Philips, so maybe they took over the part from Harris at some point.
So, what was next for me to do was to get down and dirty with my spare DME, a logic analyzer and an IDAPro disassembly listing for my firmware to try to correlate signals to code. As PRJ had mentioned at one point in here, the "key" to S702 is "MOVX @DTPR, A" instructions. Specifically, the key is cases in which DPTR is >= 0x8000 since the SRAM does not have enough addressable space to need line A15 (or A14, for that matter), yet it is there, connected to S702. Pictures are more useful than words many times, so let's get some of those going.
(images are a little large so they are linked)
I had the analyzer capture the data starting from a cold boot on my bench. As a sanity check, I counted the number of ALE pulses to make sure that they corresponded to the number of instructions executed after a reset (executed from internal ROM, hence no EPROM access). Things did match up fine (1 dead cycle from reset plus the 8 instruction cycles from code execution).
http://www.e30tuner.com/assist/M1p7_BootWaveforms01.png
Next, I made sure that the data bytes being latched from the EPROM (using PSEN) matched the hex listing. Sure enough, things looked good. The stuff seen on the EPROM data bus matched the hex listing.
http://www.e30tuner.com/assist/M1p7_BootWaveforms02.png
Next, it was time to look for some indication that data was being sent to S702. Starting at 5C00, it looked like stuff was being sent to an address above 0xA000. Since a MOVX to the SRAM makes no sense for an address this high, it seemed like a likely candidate for data being sent to S702. And sure enough, it seemed to be the case. While the RD and WR lines were used, which are also connected to SRAM, I was watching the SRAM CE1 line and it remained high (meaning de-asserted). Looks like a match...a data value of 01 was sent, as prescribed by the first MOVX instruction to 0xA081 (address not shown explicitly, but A0-A7 are 0x81 prior to sending the data).
http://www.e30tuner.com/assist/M1p7_BootWaveforms03.png
The disassembly indicates that 13 bytes are sent to S702. This is verified by the logic analyzer capture. These instructions are basically the first things done after reset (other than resetting the WDT), so I am assuming that the control registers and ports in S702 are being initialized here. The most interesting part is what happens after the 13th byte (0xFF) is sent. Suddenly the CS1 line to the SRAM goes low, enabling it for access.
http://www.e30tuner.com/assist/M1p7_BootWaveforms04.png
http://www.e30tuner.com/assist/M1p7_IdaDis01.png
Whatever that last command to S702 is, it effectively causes pin 66 on S702 to mirror the state of A15 from this point forward. This is why MOVX instructions to addresses above 0x8000 are for S702...those addresses mean A15 = 1, which de-asserts access to SRAM. In the case of M1.7, S702.66 actually connects to S550.9, which is mirrored by S550.10 which connects to CE1 on the SRAM. I am not sure why it was done in such a way. M2.3.2 seems to have a more direct connection between S702 and SRAM.CE1 (with T380 and some other stuff in between). Anyway, you can see that CE1 mirrors A15 after S702 is configured. Interesting.
http://www.e30tuner.com/assist/M1p7_BootWaveforms05.png
I am going to need to figure out how to locate more executable code involving commands to S702 and get the analyzer on there. It is tough to do on the bench since the DME isn't doing much without being in a car. But, to figure out the commands I am going to need to be able to compare what is sent to it and the states on various pins. Many of S702's pins are inputs of various sorts, so maybe I can toggle some of those and see what happens!
Cheers. I hope that this is useful and interesting (at least a little). We need 2fast4u's twin in here to post a datasheet for S702 lol.
I have a little info on S702 to share since I am doing a similar project to this with Motronic 1.7 (E30 318iS w/ M42 engine). While it is obviously not exactly a DME or vehicle that people here are concerned with, M2.3.2 and M1.7 do share the same core architecture. I figure that anything learned about S702 on one system will be helpful for people working on the other! Hopefully that is the case, anyway.
First, there are a couple of variants of the PLCC-68 S702 chip out there with different markings, but they all seem to have the same functionality. The most helpful thing I have found so far, other than the M2.3.2 schematic, is vwnut's photo on his Google Drive which shows S702 and its markings (one variant of it anyway). It has the logo for Harris Semiconductor, which Intersil acquired in the late 1990's. There is no information on PN TA13255A available on the web, but the number gives me some clue as to what it is. If anyone here developed with 8051/2/85/86/etc MCU's, they are probably familiar with the 8155 & 8255 peripheral expanders. Both of those were 40 pin devices. The S702 part pinout seems to indicate that it is some combination of the two since it takes both a clock input, as well as 3 address lines (A13-A15), along with all of the stuff common to both of the smaller chips. The "13" in 13255 is, in my estimation, Harris Semi's way to indicate that it was a larger version of the 8255. Whatever the case, it is sort of a black-box which serves a ton of functions. I see that vwnut annotated a copy of the M2.3.2 schematic to have some more info, and S702 is labeled with "30074" and "CC151V1" which are the identical markings to the part in M1.7. It is also branded as being from Philips, so maybe they took over the part from Harris at some point.
So, what was next for me to do was to get down and dirty with my spare DME, a logic analyzer and an IDAPro disassembly listing for my firmware to try to correlate signals to code. As PRJ had mentioned at one point in here, the "key" to S702 is "MOVX @DTPR, A" instructions. Specifically, the key is cases in which DPTR is >= 0x8000 since the SRAM does not have enough addressable space to need line A15 (or A14, for that matter), yet it is there, connected to S702. Pictures are more useful than words many times, so let's get some of those going.
(images are a little large so they are linked)
I had the analyzer capture the data starting from a cold boot on my bench. As a sanity check, I counted the number of ALE pulses to make sure that they corresponded to the number of instructions executed after a reset (executed from internal ROM, hence no EPROM access). Things did match up fine (1 dead cycle from reset plus the 8 instruction cycles from code execution).
http://www.e30tuner.com/assist/M1p7_BootWaveforms01.png
Next, I made sure that the data bytes being latched from the EPROM (using PSEN) matched the hex listing. Sure enough, things looked good. The stuff seen on the EPROM data bus matched the hex listing.
http://www.e30tuner.com/assist/M1p7_BootWaveforms02.png
Next, it was time to look for some indication that data was being sent to S702. Starting at 5C00, it looked like stuff was being sent to an address above 0xA000. Since a MOVX to the SRAM makes no sense for an address this high, it seemed like a likely candidate for data being sent to S702. And sure enough, it seemed to be the case. While the RD and WR lines were used, which are also connected to SRAM, I was watching the SRAM CE1 line and it remained high (meaning de-asserted). Looks like a match...a data value of 01 was sent, as prescribed by the first MOVX instruction to 0xA081 (address not shown explicitly, but A0-A7 are 0x81 prior to sending the data).
http://www.e30tuner.com/assist/M1p7_BootWaveforms03.png
The disassembly indicates that 13 bytes are sent to S702. This is verified by the logic analyzer capture. These instructions are basically the first things done after reset (other than resetting the WDT), so I am assuming that the control registers and ports in S702 are being initialized here. The most interesting part is what happens after the 13th byte (0xFF) is sent. Suddenly the CS1 line to the SRAM goes low, enabling it for access.
http://www.e30tuner.com/assist/M1p7_BootWaveforms04.png
http://www.e30tuner.com/assist/M1p7_IdaDis01.png
Whatever that last command to S702 is, it effectively causes pin 66 on S702 to mirror the state of A15 from this point forward. This is why MOVX instructions to addresses above 0x8000 are for S702...those addresses mean A15 = 1, which de-asserts access to SRAM. In the case of M1.7, S702.66 actually connects to S550.9, which is mirrored by S550.10 which connects to CE1 on the SRAM. I am not sure why it was done in such a way. M2.3.2 seems to have a more direct connection between S702 and SRAM.CE1 (with T380 and some other stuff in between). Anyway, you can see that CE1 mirrors A15 after S702 is configured. Interesting.
http://www.e30tuner.com/assist/M1p7_BootWaveforms05.png
I am going to need to figure out how to locate more executable code involving commands to S702 and get the analyzer on there. It is tough to do on the bench since the DME isn't doing much without being in a car. But, to figure out the commands I am going to need to be able to compare what is sent to it and the states on various pins. Many of S702's pins are inputs of various sorts, so maybe I can toggle some of those and see what happens!
Cheers. I hope that this is useful and interesting (at least a little). We need 2fast4u's twin in here to post a datasheet for S702 lol.
Comment