'99 OBW keyless entry is busting my chops

[jonathan909]

1 hour ago, 1 Lucky Texan said:

I should have said remote locking system - evidently, customers felt the horns were too loud and they added another horn on beginning with some later model.

so, if the horn chirped on the 11th or 12th cycle, or the 9th, what would you do?

maybe you could get some contact cleaner on the ignition switch?

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.

Quote

I'm not arguing the design, as you say,  there could be excessive contact bounce or a ratty signal that's rejected by some input filtering.....

you seem quite frustrated and it seems I haven't been very helpful so, your bench approach will likely be the best approach for you.

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.

 

Edited April 15, 2019 by jonathan909

[1 Lucky Texan]

I assumed you must have tried this many times which is why I wondered if this could be an issue just with the chirp feedback part of the circuit. There must be a parallel trigger to the horn relay or parallel relay.

I could def. see a less-than-smooth lock cylinder being tricky - maybe even needing to hold some pressure on the steering wheel so that 'steering' lock doesn't interfere?

I have only needed to program remotes twice on my 03. I was lucky and don't recall much drama. If I keep the car, the next remote may not be so easy.....

 

Edited April 15, 2019 by 1 Lucky Texan

[jonathan909]

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

[jonathan909]

1. Pulled the module from the car.
2. Programmed it on the bench using this jig.
3. 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.

Edited April 16, 2019 by jonathan909

[jonathan909]

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

 

[1 Lucky Texan]

the Data I/O has a C46 definition? (it that an 8K device ???)

does that device have a security lock?

sometimes you have to scroll a lot to find the data block

Edited April 16, 2019 by 1 Lucky Texan

[jonathan909]

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

Edited April 16, 2019 by jonathan909

[idosubaru]

Nice work - by next week you'll build your own controller!

Can you test the lock cylinder signals for fidelity, or mimic them insitu so you're not reliant on questionable signals?

[1 Lucky Texan]

5 hours ago, jonathan909 said:

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

ah, that's why the number seems weird to me, never messed with serial mem stuff. 4001 and similar, yeah. Mostly now, I help out the girls downstairs since the Data I/O 2300 promaster's DIP head doesn't work. Just PALs though, ep320, PEEL18cv8, ATV750s , etc. Using a BP Mico 1610.

maybe it isn't used for code, just temporary data?

Edited April 16, 2019 by 1 Lucky Texan

[jonathan909]

2 hours ago, idosubaru said:

Nice work - by next week you'll build your own controller!

Can you test the lock cylinder signals for fidelity, or mimic them insitu so you're not reliant on questionable signals?

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.

[jonathan909]

1 hour ago, 1 Lucky Texan said:

ah, that's why the number seems weird to me, never messed with serial mem stuff. 4001 and similar, yeah. Mostly now, I help out the girls downstairs since the Data I/O 2300 promaster's DIP head doesn't work. Just PALs though, ep320, PEEL18cv8, ATV750s , etc. Using a BP Mico 1610.

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/

1 hour ago, 1 Lucky Texan said:

maybe it isn't used for code, just temporary data?

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

[1 Lucky Texan]

not a code monkey, just a long-time tech. Used to work from masters but now almost everything is file-picked off the server(some Customer stuff is on cflash masters). We mostly just build hardware, but we customize bioses and have some code for customers they want loaded so their equip can just be pulled from the shelf so, we keep a lot of their stuff to burn. Plus generic stuff like romdos, dr dos, windows CE, linux....etc.

I work at "a long-time embedded computer manufacturer located 'near' Arlington TX"

so, the fob's pass code will reside in that part and the other chip will enabled when there's a match from the latest signal?

seems odd that it seems 'erased'. I may have spotted a post that said it was possible, but I would have thought old codes would just be overwritten with the newest???

 

 

Edited April 16, 2019 by 1 Lucky Texan

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

[jonathan909]

1 hour ago, 1 Lucky Texan said:

seems odd that it seems 'erased'. I may have spotted a post that said it was possible, but I would have thought old codes would just be overwritten with the newest???

Exactly - the part isn't full of zeroes - I know that because the module works.  This is definitely a problem with the Unisite failing to read it - I'm going to fiddle with the device codes to see if that makes a difference.  I just wish I had some DIP 93C46s in stock here to play with.  Can't see any.

[jonathan909]

Buggah!

Figured out why I couldn't read the 93C46 - turns out it's available in this funky alternate "rotated" pinout - it's not shown in the ST datasheet (that's whose part is in here), but it is shown in the Atmel datasheet, and that's the version that Alpine used (for whatever ungodly reason).  It's a packaging option that's only available in the SOIC (not the DIP), so (of course) Data I/O only supports it in their SOIC socket.  Which I don't have -  I only have the DIP and PLCC sockets on the Unisite, which is why I mounted the SOIC on a DIP adapter.  So now I've made another adapter to rewire all the pins and it's reading like it oughta.  Cool.

[1 Lucky Texan]

wonder if it was cheaper, or done to make 'cloning' the circuit more difficult for the competition?

auto suppliers often work with fractions of a cent for bidding a job.

you're probably in for smooth sailing now.

Edited April 16, 2019 by 1 Lucky Texan

[jonathan909]

Oh, who knows... could have been a designer with a formal stick up his butt over using a JEDEC pinning (however screwy), or the rep or disty giving them a good price on these ones because they're oddball and nobody was buying them... any number of stupid reasons.  Certainly not to prevent reverse-engineering - too trivial a change, and the microcontroller's software (the part that counts) is locked up in mask ROM that effectively can't be read out anyway.

[jonathan909]

I've now hacked the security module onto my test jig and answered the question I started with last spring.

"Valet mode" does not inhibit the programming of new key fobs (transmitters).  I suspected that it does because my '02 Forester arrived in valet mode, without a working fob, I couldn't get it into programming mode to connect a new fob, and someone over on NASIOC claimed that a Subaru tech told them that it does.  I've now disproven that theory, and think that the same problem normally experienced preventing entry into programming mode was at work:  A badly worn keyswitch.  I continue to work toward (dis)proving this thesis.

Edited April 17, 2019 by jonathan909

[jonathan909]

On 4/15/2019 at 8:05 AM, 1 Lucky Texan said:

Maybe you could get some contact cleaner on the ignition switch?

That's starting to sound like a plan.  I just spoke to the dealer (and confirmed online) that the switch is not a separate part from the lock, so the whole assembly has to be replaced (~ $150 USD, $300 CAD).  And that assembly was only used for a couple of years, so the idea of getting one from a much newer donor car is a nonstarter; one from a car of the right vintage is probably going to be as worn and noisy as the one you're trying to replace.

[1 Lucky Texan]

I once did this (well, a poor attempt) in a Honda decades ago and the CC flushed lube from the lock - had to re-lube the lock.

of course, I didn't disassemble the column, just tried squirting in THRU the lock ! lol

it was almost a disaster, the lock was seized for a while!

 

[jonathan909]

You may not have been careful enough in your choice of contact cleaner.  It's easy to get one that's a cleaner and killer degreaser that, as you say, flushes out any lube.  I always go for the cleaners that have added lubricant.

[jonathan909]

And here it is with the security module added.  I really need to quit screwing with this stuff and go do something else...

Edited April 18, 2019 by jonathan909

[heartless]

2 hours ago, jonathan909 said:

And here it is with the security module added.  I really need to quit screwing with this stuff and go do something else...

 

Please don't.. lol

I don't know much about this kind of stuff, but find it fascinating reading. =)

[jonathan909]

Okayokayokay... if you're having fun watching me obsess over it (sicko), I've got one more bone I can toss you for now.

I threw the 'scope on the three wires that are used for communication between the two modules, and at first glance it doesn't appear they're running anything as complicated as the synchronous serial protocol I speculated about earlier.  I haven't done much with it yet - just watched the lines when I enabled and disabled the security system - and I think they just strobed one line to signal the change of mode.  I'll have to read a little more closely to see how many different states there might be and try to correlate that with how the state change signals might be encoded, and look at the microcontroller's data sheet to see what the pins (on each board) serving those three wires are capable of.

Other than getting in and out of valet mode I haven't been very interested in the security module, so I don't get yet what-all sets it off.  The easy thing to do on the bench is just give the shock sensor (that little grey box in the upper right) a little rap, but obviously there are a bunch of other conditions that can trigger it, so they'll represent different messages being passed.  We'll see about all that later.

[heartless]

Quote

Okayokayokay... if you're having fun watching me obsess over it (sicko), I've got one more bone I can toss you for now.

ok, maybe I am a little weird..

but, this is how I learn a lot of stuff.. by reading and following along with others as they do things.

Granted, I am not going to turn into a tech from all of this, but I will end up with a very basic understanding of how it all works.

So, please, do update as you tinker with it and figure things out so my inquisitive nature can soak it all in.