jonathan909

Yes, essentially. When you do the programming, the MCU stuffs the fob's code into the E^2. Then, in normal operation, when the MCU gets a signal from a fob, it looks it up in the E^2. If it matches, it does its thing. The interesting part from a reverse-engineering standpoint is that the system supports up to four fobs. You can't erase a fob's code - you overwrite it. So if you want to clear out the existing codes, you take your new fob and program it in four times. That has the added feature that if we then look at the contents of the E^2, we should see the same block of data repeated four times, which will tell us where and how the fob codes are stored in that memory. Not that knowing that is actually useful, but it's cool to know. And now that we know what the MCU is, we've confirmed that the E^2 is where the fob codes go, because the 750008 only has RAM and ROM on board - no E^2. The other thing I'm interested in is how the keyless entry and security modules communicate with each other. They're connected with three wires, which suggests they talk via the same SPI/Microwire/whatever synchronous serial interface as the MCU uses to communicate with the E^2 - except that there's usually a select line in addition to the Din, Dout, and clock lines. So I'm not there yet - still have to add the security module to my jig and throw the scope (and probably the logic analyzer) at it.

I'm a huge fan of programmable logic - have been for a really long time. Even before I bought the Advin for doing PALs in the late 80s I was using small bipolar PROMs for memory decoders and stuff via the 29A and Unipak2, since I couldn't afford a LogicPak. In the modern era, though, my work has had a lot of Xilinx FPGAs and FLASH CPLDs (and some Atmel parts as well), and all those things are ISP via JTAG, etc., so the old programmers largely gather dust - they get dragged out for weird gigs like this one. I don't know about your background, but I'm guessing you'll get a kick out of this (I wrote it just a few weeks ago): https://nitpickingbastard.wordpress.com/2019/03/28/on-the-trail-of-the-mcu-part-2-what-the-hell-is-a-lattice-gal-doing-in-my-stove-hood/ Yes, exactly - these serial E^2s are too small and slow for code, so they're used for configuration data that needs to persist (like fob codes). The 44p QFP you see in the corner is what's doing the work, but I don't know anything about it - it has an Alpine house number. But I'm beginning to think it isn't a full-custom part, as I have a newer rev of this module (fetched from the junkyard) that has a sorta-similar layout, but a NEC part in the same package in the same spot. So it may be a mask ROM MCU that I can actually look up, which makes a lot of sense... Yup, that's exactly what it is - a NEC (now Renesas) uPD750008 4-bit mask ROM MCU. And the security module has a similar layout as well, right down to those two same packages in the same corner, which is where I started thinking about this last spring: Wondering whether I could find the (presumed) bit in that E^2 that tells it that it's in valet mode. I'll get there...

Could do that (and once upon a time I did some life cycle testing on a custom switch assembly over exactly this kind of contact wear), but I'm not interested in getting that obsessive about it, since the jig gives me an effective workaround. Actually, now that I think about it, the logical next step would be to just hack a pushbutton onto the module (across the pins where the keyswitch goes) and see if it will get me into programming mode. If it works, we can reasonably infer that the problem is keyswitch noise without getting way into the deep end trying to characterize that noise.

No, just 1K(bit) - organized as 128x8 or 64x16, neither of which take much scrolling. The giveaway is that the Unisite reports a $0000 checksum, so that tells you at a glance it got nothing but zeroes on read. It's not a uC, just a memory, so there's nothing like a security bit. It's really bugging me that the Data I/O is having trouble reading it, so I'm going to have to mess around, see if I've got some more of these chips I can experiment with i.e. burn some random data into. And annoying that it seems to be the only programmer I have that's supposed to support them - I've got a 29A, 29B, Advin Sailor PAL, etc. Friend of mine has an Advin Pilot (which is supposed to support them as well), but he can't find it. Grrr...

And here's another unit, out of its box and with the EEPROM socketed so I can take it out and spill its gutz.

Pulled the module from the car. Programmed it on the bench using this jig. Reinstalled it in the car. Works perfectly. I haven't tried programming it in the car, but I don't expect it to work. When I get the time and inclination I'll probe the connector and see if I can see anything wrong, but I still strongly suspect a worn ignition switch. This also doesn't solve the stuck-in-valet-mode problem that I had with my '02 Forester last year. That's a function of the optional security module, which ties into the keyless entry module. I don't want that part, so I don't care much, but sooner or later (probably sooner) curiosity is going to get the better of me and I'll add it to this jig. p.s. Other than the chunk of harness taken from a car in the junkyard, built entirely of stuff I had lying around.

[later] The good news is that my test jig is done and works perfectly. I've tried a few of the keyless entry units and they function exactly according to the description. So I can program one for the key fob(s) I want to use, then install it in the car and assess it for operation, both in "normal" use and in programming mode. If it doesn't work for normal use, isolating the fault in the car wiring should be quick work. If it does work, but won't enter programming mode, the keyswitch is still my first suspect. [geek mode] The one weird problem I'm having in the lab, though, is with the EEPROM that Alpine (presumably) stores the fob codes in. It's a serial E^2 - 93C46, an old and very common part, and the Data I/O Unisite I'm trying to read it with is returning all zeros - nothing that looks like proper data. Not sure what's going on there. [/geek mode] Will post a picture later.

That might or might not help. The contacts aren't the only issue, either. The key/cylinder are worn and don't turn smoothly - catching sometimes - compounding the problem. The right answer is a new switch assembly, but then the (re)keying becomes a thing. What's stuck in my craw is that I haven't gotten the beep at all - not on 9, not on 12, never. And I refuse to believe that the problem is in all of the four or five modules I've tried. Nor is it something blindingly obvious like a door not being closed, and there just aren't that many inputs into this controller. So it's a puzzle, and we solve puzzles. Oh, I started with "frustrated", but I'm way past that now. Once you put yourself on a path to solving a problem, you're no longer frustrated - you're just "in the process", and the bug will inevitably fall. It's just a matter of time. Wrt "helpful", to the contrary: Any discussion that focuses thought and clarifies the problem helps, and I appreciate it.

When I say "we can be certain that it wasn't designed that way", I do so with some authority, because I design systems like this (and have done so for about 40 years). If the manual says "ten times", that means the EEs and programmers behind it built it to work that way, and you can take that to the bank. Nobody builds a sequence like this around an approximation, because: a) it's harder to do it that way, and b) they want it to work the same way every time, regardless of whether it's on their bench or out in the field. Consistent, repeatable behaviour is the norm, and deviation is a defect that suggests bugs. Nobody wants to get calls from dealers and customers complaining that it didn't work exactly that way every time it was used. Would you tolerate that behaviour from your speedometer? Your radio? Your airbags? Joe Spitz's "appr 10 times" is to be dismissed, along with his statement about the brake pedal, as myth. He's a car salesman (and I've been in touch with him over this) who assembled his page as a convenience, not an engineer who's reporting definitive data. I've been over the schematics, and with this Alpine system it's the same horn and same horn relay as the driver uses. That's the only feedback provided to indicate programming mode; whether that was a good design decision is a different discussion. So I'm becoming increasingly convinced that "fixat(ing) on the number 10" is exactly what will solve this. Switch contacts get noisier, and key cylinders get stickier, over time. I think that the designers, with brand-new keyswitches on their bench, made it work consistently, but failed to factor in the switch wear over time in building their debounce and delays simply because it's not their primary concern. The "security" aspect you raised is different - in this generation that's a separate module not present in all cars, so it carries its own implications outside of the scope of what I'm doing now.

Perhaps, but we can be certain that it wasn't designed that way. It only suggests I'm on the right track.

For anyone (?) interested, an update: Collected a few more of the modules from the boneyard today. Tried one of them in the car to no change in behaviour. I'm beginning to suspect that the problem is with the ten-key-twist. As the car gets older, so do the switches, including the ignition. If that switch becomes sufficiently noisy, then, depending on how well Alpine implemented their switch debounce, the keyless entry unit may not be able to accurately count the ten cycles, and that's all it takes for a deal-stopper. Should have my jig finished tomorrow, so I can start doing more controlled experiments.

Presumably your alternator is mounted as usual - on the AC compressor bracket. So that's your starting point - you bolt through the compressor into the four threaded holes in that bracket, so you need to find a compressor with that hole spacing.

Yikes - I was in a similar situation with my '98 Legacy wagon - somewhere along the way the AC (compressor and condenser) were removed and the PO didn't bother replacing them. When I decided to take care of that last summer I just had to dig around the wrecking yard to find the compressor+brackets that fit, as there are abundant combinations that don't.

Right - there are a bunch of those stupid little variables whose existence may or may not be rooted in fact. The manual is quite clear about the key being OFF ("LOCK") at the end of the 10 twists, but there's no mention of the brake at all. The only place I've seen the brake discussed is on Joe Spitz's page (the cars101.com piece mentioned above), and since the brake is not an input to the keyless entry module, I believe this is a myth. I'm not certain about anything. But I do have about a dozen fobs with fresh batteries, so the odds are in my favour that I have some good ones. And I'm in the process of building a bench jig so I don't have to do this out in the car. I'm annoyed enough at this business that I intend to have its pelt nailed to the wall before long.

No idea whether it's possible with the '05, but I did it with the '99. Undoing the motor mounts and firewall/xmission strut and lifting the motor a few inches would have made it easier.

I've been over the schematics and there's no connection between the Alpine keyless entry module and the OBDII, so unless there's some path through the security module, the SSM can't do anything with this one.

Dense white smoke usually means burning coolant, so head gaskets it is.

That one's gonna be a 25.

That's what I was thinking - if the belt broke at the right time, maybe the valves could snap shut before getting hit, in which case all four would still show "normal" compression. But those odds seem a little slim to me, making the belt break less likely. Get that cover off! Inquiring minds want to know!

(Getting pretty far OT now...) Ours was 7% when it was first introduced, but it was backed down to 5% as part of an election promise some years back.

Well, not so much. Your $11 USD = $14.65 CAD today. They charged me $17.55 + .88 GST = $18.43 , which I rounded up to $20 for convenience.

Okay, thanks. Sounds like I'm going to just take this one on faith - I picked up an OEM PCV from the dealer, $20 vs. $5 for the aftermarket part (a massive difference in relative terms, but bupkis compared to value of the engine...).

I'm confused. Since crankcase -> intake is the normal direction of flow, why doesn't that happen anyway, regardless of whose valve it is?

Those sensors are passive devices and inherently pretty reliable. I'd have to take a look at the drawings to see what else might deprive you of spark, perhaps an ignition relay [edit: the "main relay"?]. Of course, a defective ECU could also be responsible, as it's what takes those sensor inputs and outputs the spark signals.

Forgive me for being slow, but are you saying that the failure mode is that the valve fails shut and excess pressure in the unventilated crankcase forces oil into the cylinders?