No announcement yet.

S702 information

  • Filter
  • Time
  • Show
Clear All
new posts

  • S702 information

    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).

    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.

    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).

    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.

    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.

    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.
    When trouble arises and things look bad, there is always one individual who perceives a solution and is willing to take command. Very often, that individual is crazy. - Dave Berry

  • #2
    CC151 is for know control as far as I know. Data sheet I'm also looking for.


    • #3
      I contacted Intersil directly to inquire about the part yesterday. The replied that they have no record of the PN TA13255A, and that many of the old Harris Semi parts did not have their data transferred when the company sold its chip division.

      I am going to try contacting Harris next. Even though the company is now in a different business sector, maybe they have archives. Fingers are crossed!
      When trouble arises and things look bad, there is always one individual who perceives a solution and is willing to take command. Very often, that individual is crazy. - Dave Berry


      • #4
        very nice work bmwman91!!!!!
        "The really good drivers got the bugs on the side windows." Walter Röhrl


        • #5
          Originally posted by bmwman91 View Post
          I am going to try contacting Harris next. Even though the company is now in a different business sector, maybe they have archives. Fingers are crossed!
          They do, but they will not share this information with you because it is the property of Bosch.



          • #6
            When you have this statement. Let me know. I will ask Bosch in Germany. They send me MAF sensor data sheets already. I guess it’s only a matter of time to get something.


            • #7
              They will not share that data, it is proprietary under NDA.
              Some of it was 20 years NDA, some of it was lifelong. Most electronic parts incl. the electronic schematic are under lifelong NDA.


              • #8
                Sure, I would expect that this part is under NDA. I have found over the years that asking never hurts. It is rare, but every once in a while you get lucky. As time passes, staff changes at these companies, and super old parts like this which pre-date whatever current documentation control system the company currently uses. It is of course a "mistake" on their part to release it, but the chance is not 0% (maybe 0.1%, but that is still non-zero and asking is free).

                Since I am not counting on Harris, Philips or Bosch to give me the datasheet, there are a few options remaining.
                1) Stop worrying about it and just continue letting S702 do what it is currently doing without fully understanding it.
                2) Stimulate input pins and probe the interface between S700 and S702 to see what happens. Also watch for data transfers prior to the firing of the TTL ignition drive signals from it (this is M1.7 specific).
                3) Decapsulate the PLCC and optically image the die to try to determine function at the transistor level. There is actually some freeware out there which can automate the conversion of the image to a schematic and Verilog-style logic simulation. This is something I have wanted to do for a long time (to any chip really, just for fun). I work in an industry where I have access to the necessary chemicals and very very expensive precision metrology equipment, so this is not at crazy as it sounds. My employer also has a 3D-Xray / CT machine, but the chance of me getting time on it for a personal project like this is pretty low.

                PRJ and others, I do have a question for you about S500, which is the last major link in the chain for ignition drive in M2.3.2 (and second-to-last in M1.7).
                - In M2.3.2, it looks like logic-level coils are used which have integrated current drivers / voltage clamps. S500 has 5 outputs, and 3 inputs (so I am assuming that the output is selected as a 3-bit encoded number on the inputs)
                - In M1.7, the ignition coil drivers are in the DME, and S500 serves as a base current driver to these (relatives of the BIP373 or BU232Z). There are 4 TTL inputs to S500, which look to be mapped 1:1 to the 4 outputs.

                A partial schematic for M3.1 which also uses S500 shows 6 inputs & outputs, plus some other pins which I assume tell the chip whether to map inputs to outputs using a parallel or 3-bit encoded scheme. Got any info on which pins control the interface type? It is not terribly important, but it is a small curiosity. If I do end up decapsulating a spare S702, I guess I can also do S500 which I imagine has a MUCH simpler die.
                When trouble arises and things look bad, there is always one individual who perceives a solution and is willing to take command. Very often, that individual is crazy. - Dave Berry


                • #9
                  OK, so I had 30 minutes free at lunch today, and I got about 5% of the way into reverse engineering S702 directly. Forget the nitric acid and whatnot, I took a little more of a brute force method to get the plastic encapsulation off. While I have pics of the (comical) process, I won't bog the thread down with those unless people want to see it. The short version is that I ground the leads off of the PLCC, stuck it in a bench vise with the tops of the jaws aligned with the centerline of the package where the ground-off leads protruded, and repeatedly applied clamping force while rotating the part between compressions. The plastic fractured in half and popped right off of the die.

                  A couple of quick sample images are below. Here's S702 in all of its glory lol. There is a clear conformal coating over the die still, which is why it looks a bit distorted in places. It will have to be removed chemically. Imaging was done on a Keyence VHX-2000 3D microscope. It makes this stuff super simple since you basically just specify X/Y/Z bounds and it will automatically pan over the entire area and through all focal planes, pick the in-focus pixels and stitch adjacent images together.

                  (click thumbnails for slightly larger images...for the purposes of not uploading monster attachments, these are heavily shrunk from the originals I got from the microscope)

                  An overview of the silicon die in its entirety. It is fairly simple stuff compared to just about everything today.
                  300X mag
                  Full-size image of the die (~8MB):

                  Definitely a custom part made specifically for Bosch.
                  500X mag

                  There seem to be 2 types of structures around the pads where the IO pin microwires insert.
                  Here is one type.
                  1500X mag
                  And here is the other type. The smallest feature I found was spacing on the order of 1.5um, with most traces being 2-5um wide. On the one hand, it is made possible by thousands of years of human progress and science, and on the other hand, it is easy to wave it off as being "ancient" technology compared to today's semiconductors which are ~150X smaller in feature size.
                  1500X mag

                  I am not sure how much time I am willing or able to put into going much further with this, but it is sort of neat to see the guts of this thing. Like I said at the start, this was a quick 30 minute project and probably 5% of the work needed to actually reverse engineer this in a meaningful way.
                  Last edited by bmwman91; 5th January 2018, 19:36.
                  When trouble arises and things look bad, there is always one individual who perceives a solution and is willing to take command. Very often, that individual is crazy. - Dave Berry


                  • #10
                    A bit more info on S702 to share.

                    1) There are three types of ports present in the chip, which can be identified visually from the die images. The types are:
                    a) Input-only - one metal trace connected

                    b) Output-only - two metal traces connected

                    c) Bidirectional input/output - three metal traces connected

                    2) I catalogued the pins and made a list, which I then compared against the known connections from various Motronic schematics. The visual correlation of pin types matched the functional uses perfectly. Here is a listing of the pin numbers, the "labels" from the schematic and the port type.
                    Pin Label Type
                    1 ??? Out
                    2 CLK In
                    3 TV0/I10 In/Out
                    4 TV1/I11 In/Out
                    5 TV2/I12 In/Out
                    6 TV3/I13 In/Out
                    7 TV4 Out
                    8 PL Out
                    9 RESOUT Out
                    10 P2.7 In/Out
                    11 P2.6 In/Out
                    12 P2.5 Out
                    13 P2.4 Out
                    14 P2.3 Out
                    15 P2.2 Out
                    16 P2.1 Out
                    17 P2.0 Out
                    18 HST In
                    19 P1.0 Out
                    20 P1.1 Out
                    21 P1.2 Out
                    22 P1.3 Out
                    23 P1.4 Out
                    24 P1.5 Out
                    25 P1.6 Out
                    26 P1.7 Out
                    27 WUP Out
                    28 VTH In
                    29 I9 In
                    30 I8 In
                    31 I7 In
                    32 I6 In
                    33 I5 In
                    34 GND PWR
                    35 I5 In
                    36 I3 In
                    37 I2 In
                    38 I1 In
                    39 I0 In
                    40 RESET In
                    41 ??? Out
                    42 RD In
                    43 WR In
                    44 D0 In/Out
                    45 D1 In/Out
                    46 D2 In/Out
                    47 D3 In/Out
                    48 D4 In/Out
                    49 D5 In/Out
                    50 D6 In/Out
                    51 D7 In/Out
                    52 ALE In
                    53 A0 Out
                    54 A1 Out
                    55 A2 Out
                    56 A3 Out
                    57 A4 Out
                    58 A5 Out
                    59 A6 Out
                    60 A7 Out
                    61 PRG In
                    62 INST In
                    63 A13 In
                    64 A14 In
                    65 A15 In
                    66 CS0 Out
                    67 ??? Out
                    68 VCC PWR

                    3) Progress in understanding the control registers and command list is slow, but I have made a couple of small gains in this area. There are 6 controllable bidirectional pins (3, 4, 5, 6, 10, 11). The listing of the 13 commands sent from S700 to S702 at boot is shown below. You can see that there are 6 "small" low-byte addresses sent with a value of zero, which I am assuming is where those 6 pins are configured as outputs.
                    DPH DPL Data
                    A0 81 1
                    A0 10 81
                    A0 11 81
                    A0 40 FF
                    A0 41 FF
                    A0 2 0
                    A0 3 0
                    A0 4 0
                    A0 5 0
                    A0 8 0
                    A0 9 0
                    A0 21 D7
                    A0 20 FF

                    4) Pins 19-26 are listed as making up Port1 in the schematic. They are also output type pins, and immediately after FFh is sent to address A040h they toggle from low to high, so address A040h seems to be related to Port1. However, that same address is written to in other parts of the main loop and it does not toggle any Port1 pins, so there's more to it I assume.

                    5) Pin 66 looks to be configured as a buffer for A15, and it is used to toggle the RAM chip's enable pin. There is a possibility that the output of Pin 66 is a logical OR of A15 and A14 though...I need to confirm this with a small dummy program to mess with address lines.

                    6) Pin 67 appears to behave as another logical output. This one seems to be (A13 OR A14) OR (NOT A15). Again, I need to test this with a dummy program since A14 is never high when A15 is low as far as I can see in the stock ROM. My guess is that this is for an additional RAM/ROM/expander chip enable signal.

                    7) Pin 27 which is labeled as "WUP" in the schematic is not connected to anything in M1.7, but it is in M2.3.2. Despite this, it toggles between low/high every 10ms in my DME, immediately after S702 is written to (data FDh to address A040h). I do not observe any other outputs changing when this command is sent, so I have no clue as to why it is in the firmware to do this with an unused pin.

                    8) Eight other IO pins (the 6 bidirectional ones plus 12 & 13) change state after the 13th byte is sent during boot. Also, only 1 of the 8 is actually connected to anything in M1.7 lol. However, their state transitions do not seem to correspond to any of the data bytes that were sent, so it may be that they are not accessed as "ports" in the same way that S700 and most microcontrollers do. Maybe S702 is more akin to an FPGA (they layout does look like a gate array, which was also the technology of the time period).

                    9) I assume that there is some sort of timer/counter onboard, based both on PRJ's comments about it and some of the stuff in the silicon. Pin 2 is the "CLK" input, and I followed what I think is its trace through the die to an area with 6+ symmetric blocks of transistor logic. These may be the gate arrays which form the counter.

                    Anyone have a friend at Bosch who owes them a favor? Maybe we can all chip in for some really nice beer for them? That would certainly be easier!
                    When trouble arises and things look bad, there is always one individual who perceives a solution and is willing to take command. Very often, that individual is crazy. - Dave Berry


                    • #11
                      I contacted Bosch and some friends to get the datasheet
                      The DPH and DPL I have already seen in the ASM code but I'm not sure if this is really for this chip or some internal address...


                      • #12
                        Very good, thank you for contacting your connections. This puzzle is pretty tricky! As fun as it is trying to figure out the "black box" from the outside, a document which simply explains the logic is better so that we can all focus on ROM code.

                        I have mostly confirmed that DPTR is used to access S702 since I can see some IO pins change as a result of the boot commands sent to it.

                        The following is the case for M1.7, and I assume that M2.3.2 has similarities...
                        Program space is broken up as follows:
                        0000h - 1FFFh are S700 internal ROM
                        2000h - 7FFFh are the EPROM addresses 2000h - 7FFFh
                        8000h - 9FFFh are the EPROM addresses 0000h - 1FFFh (A15 goes high, but it has no connection to the EPROM)

                        Data memory is mostly as expected, although S702 falls into here:
                        00h-7Fh are S700 internal RAM lower half
                        80h - FFh are SFR's and upper RAM depending on access method
                        0000h - 1FFFh are external SRAM accessed via (INSTR)X
                        A000h - ????h are accesses to S702 via (INSTR)X

                        Looking forward to any info on S702 that we can get!
                        Last edited by bmwman91; 8th January 2018, 21:38.
                        When trouble arises and things look bad, there is always one individual who perceives a solution and is willing to take command. Very often, that individual is crazy. - Dave Berry


                        • #13
                          It's been a long time since I RE-d it but.
                          Look how the bitfield is loaded that contains for example TPS switches, idle switch and so on. This will give you a hint how to request data.
                          Also, all the S_XX things are actually connected, even if not used in the ECU.


                          • #14
                            Yeah I think that I will need to do logic probe measurements with the DME in the car, not on a bench. There is very little to observe on the bench!

                            In my DME, S702 the ignition coil control goes through S702. The chain is S700 > S702 > S500 > T501-504 > Coils 1-4. I assume that S700 either times its commands to S702 very precisely to start dwell and fire the coils, or it initiates the dwell and gives a dwell period with which S702 uses its internal counter to make the second pin state change. Do you remember if S702 has the ability to set pin timings using its internal counter?

                            What did you mean by "S_XX things"? When you RE'd the chip, did you do it all by observing the ROM code and IO pin behavior, or did you have other methods?

                            Thanks a lot!
                            When trouble arises and things look bad, there is always one individual who perceives a solution and is willing to take command. Very often, that individual is crazy. - Dave Berry


                            • #15
                              Download M2.3.2 schematic and look at the switches going into it.
                              In our ECU S702 has nothing to do with ignition, that gets output from S700 via a simple programmable trigger and the S250 intercepts it acting as a solid state distributor and knock box.