im not sure what's up with that. the new beta uses qelapsedtimer instead of trying to make my own, it'll probably work better. give 'er a shot
im not sure what's up with that. the new beta uses qelapsedtimer instead of trying to make my own, it'll probably work better. give 'er a shot
eehack was fundamentally broken with respect to timing. the way i was doing post-command delay timing had a huge blunder in it, which is really critical because the ECM has a lag time after a command is received before another one can be processed
it's just a fluke that my in-the-wrong-place delays were long enough to make everything work alright (actually really well, considering)
that does explain some of the random flash operation failures that magically got a bit better as the 'failsafe' delays were put in place.
i don't have a working ECM to test it on. hopefully that changes tomorrow.
came home with two socketed ecms from work today, just need to dig up my chinese programmer and it's go time!
driving me a bit nuts trying to get these working; i've got two ecms socketed (one on both sides, one only on the t-side as i know the e-side is still good - i get comm responses from it)
i tested all the socket pins for continuity
still no comms on any of the chips i've flashed but the e-side on that one ecm is still talking, so i know my bench interface is ok...
using the images in this thread http://www.gearhead-efi.com/Fuel-Inj...for-95-LT1-PCM
anyone have any ideas?
Probably something to do with the programmer, maybe an address offset or a selector switch flipped wrong?
you'd figure;Originally Posted by Xnke
64k bin, 64k eeprom, so no offset is even really possible
there are no selector switches on this programmer, it's all software controlled, with a specific mode for the n28f512, i write the bin, read it back, and it's identical.. so i THINK its programming correctly..
I used the bins posted by 96lt4c4 to fix my PCM and they worked for me. Then, with a working PCM I bench re-flashed my bin. I can't recall the exact details, but I know the programmer I used was set to put the wrong pattern on the chip for the blank areas by default. I'm 99% sure it was putting 00 instead of FF for the blank areas. The only way to know this is by looking at the raw data programmed to the chip. Otherwise, you pick the setup and it would just program and seem correct.
I'm not sure why the wrong pattern in the blank areas matters, but it seems to. You'd think that blank parts of the flash memory would never get read by the processor so the contents wouldn't matter, but in practice I had seen proof that it does. A simple checkbox in the programmer software makes the difference between the processor on the board using the memory chip running the code or not.
I figured out that the programmer was doing it wrong by reading the chips I had pulled off the board. When I had the issue, CATS had programmed the whole PCM without a "failure" but the engine still wouldn't run so I figured the flash chips from the board had to be close to correct. Comparing the data from the original chip vs one I had programmed showed the obvious difference with big areas of FF vs similar big areas of 00, so I knew a setting was wrong.
As a backup, I have a 96 or 97 PCM (that went through an engine fire) with a VATS bypass oscillator circuit I built so I can swap it into the car to move it if it's needed. I only program in the garage or just outside so I can park the car if it fails. The failure I had programming the thing justified going "home" before flashing.
Last edited by lionelhutz; 01-19-2016 at 08:35 AM.
i now have a second bin that someone sent me; the bins in that thread you used are full of 0x00 where 0xFF is in the other bins should be. i don't know how it's possible for a programmer to know when to byte swap 0x00 to 0xFF, because there are obviously some sections that should actually be 0x00 too.Comparing the data from the original chip vs one I had programmed showed the obvious difference with big areas of FF vs similar big areas of 00, so I knew a setting was wrong.
hoping this does the trick!
something is still odd; it's not working at all
as a side project I really have to figure out how the bin is being translated, is it a bit order thing or some wacky address offsetting? Once I manage to get the ecm actually working and read the bin back, it should be trivial to figure out.
But the other question is why, obviously not to stop tuners, unless they were dumb enough to think that nobody would replicate the tech's flashing routine.. maybe it's a natural consequence of a non-standard pin-out to the processor that causes reordering?
I suggest you pull the last chip read it and see what`s inside.
Also put the chip in the other PCM and see If it will work there.
Make sure the chips don`t go too deep in the socket. And double check all the solders.
still no luck
you'd figure out of three sockets, one of them would be working, but the only response i get is from that last chip still soldered to the board.
i tested every pin on the socket again, and they all seem ok, and my soldering job is really good.
it's pretty frustrating
i'd believe that i nuked a board playing around with it, but three dead boards? seems unlikely
Are the sockets oriented correctly on the board? Some PLCC sockets will mount to SOME pad patterns two different ways....
Also when the chips were removed, was the conformal coating cleaned sufficiently, it's possible that one or two pads didn't make a good join, etc.
All stuff I'd start looking at.
one nice thing about this PCB is the chip is almost completely traced to a series of solder pads right next to each contact, so there are good test points. i've had the multimeter out quite a few times checking, and it's possible i missed one, or maybe one broke free as i've removed and reinstalled the chips so many times. i'll check them all again.
Here are some fresh raws and corresponding flashread bins.
I tried both ff and 00 version on fresh intel n28f512-200 chips.
For my surprise the 00 version worked, because last time i tried them they didn`t work. Another thing I noticed that during testing my programmer freak out and always there were errors on the chip even though the verification passed good.
After 2 hours rest time the programmer fixed itself and start working correctly.
Hope you triple check the bins written on the chips. I am sure it will work at one point.
Posting Permissions
Reply With Quote
Bookmarks