any testing would be appreciated!
-try my new software downloading your bin a few times
-load up my eex definition in tunerpro and look at your bin
once you're confident that reading the bin works properly you can try flashing
as long as you dont cut ignition power to your ecm while its erasing or flashing the first part, it should be good enough where we can recover it (i hope)
eehack flashes too though
so here's the struggle... look at the difference in aldl request timing!
the bbody bin spits out messages at a much higher rate.
between windows drivers and serial interfaces, this confirms the precise approach of sending a request between packets is impossible. i am going to come up with something way better. i want to try to abuse the length and checksum to basically 'hang' the bus and then unhang it at the same time that we send the request....
FBODY:
BBODY:Code:159ms to 175ms (16ms) :: F056F4C6 ::: GAP34ms 209ms to 231ms (22ms) :: 905A02080008FF05 ::: GAP31ms 262ms to 285ms (23ms) :: 0A58FF00009F ::: GAP27ms 312ms to 330ms (18ms) :: 905A02080008FF05 ::: GAP31ms
Code:::: GAP0ms 0ms to 17ms (17ms) :: 92551919 ::: GAP9ms 26ms to 42ms (16ms) :: A6550505 ::: GAP9ms 51ms to 68ms (17ms) :: F056F4C6 ::: GAP9ms 77ms to 103ms (26ms) :: 405F020400870000007F00480D ::: GAP0ms 103ms to 132ms (29ms) :: 4563000000000000080000000000A0A010 ::: GAP5ms 137ms to 154ms (17ms) :: 12559999 ::: GAP21ms 175ms to 194ms (19ms) :: 10559B9B ::: GAP9ms 203ms to 218ms (15ms) :: 92551919 ::: GAP9ms
okey dokey! i did load a b-body bin and found it did fail a lot of the time, even on a bench harness, you were not kidding around.
try this beta which seems to solve the problem 100% of the time with a more of a machine gun rather than a pistol. fortunately there are very few civilian bystanders in an aldl bus so nobody should be hurt.
http://fbodytech.com/flashhack/
What's amazing is that I've flashed literally dozens of B-body tunes through this exact same interface and NEVER had a brick with eehack.
Summary:
1. Read with no errors.
2. Wrote with no errors.
3. Pulled USB during T side write, was able to recover after some clunkiness with the USB and flashhack.
4. Pulled USB during E side write, same as above. Specifically wrote only the E side afterwards, had no issues.
5. Tried out the PCM with EEhack, seems to run fine on the bench.
Well done! Emailed you a log.
nice. i feel bad i even tried a precise approach when we just needed to smash the bus appropriately.
yes pulling the usb cable might require a program restart.... it's a pain to check if the bus is actually still there with every single byte and most programs that deal with usb devices will throw a total fit if you unplug it mid-byte. as long as it recovers if ECM ignition power wasn't cycled in that condition i'm happy.
edit: i guess if it's possible could you huck that the ECM in a car and make sure it actually runs with kur4o's crazy recovery patch in place?
Last edited by steveo; 04-15-2020 at 07:32 AM.
Maybe midday tomorrow. The car currently has nothing more than manifolds, no cooling system, accessories or transmission. I cobbled it together enough to start it and verify oil pressure, ignition and fuel. Now time for the rest of the car to go back together. BTW you know how you can tell if an LT1 ignition and injectors are good? When it starts up with a BOOM exactly 1/2 second after you crank it. Every time. Scared the crap outta my kids, LOL. "Son, what was the oil pressure?" "I dunno dad I was duck and covering." "I TOLD you it'd be loud! What's the oil pressure!?" This was WITH everyone having ear protection on!
Woah! Sorry for not getting back to you sooner, I was a little busy in the "real world" doing boring stuff. But yeah, I went ahead and gave the new beta a test. Still didn't work, but I've got some new logs for you to check out.
The first log I forgot to tick the 'timestamp' button, apologies there. The fourth log is from my manual '95, just to see if it did anything different. It still failed to read, so doesn't look like it.
As always if there's anything else at all I can do to help just lemme know--I will likely have more 94-95 Corvettes in the future, so I'd love to join your F-body flash party. :)
Oh yeah, and the adapter I'm using is the one from ALDLcable. http://aldlcable.com/products/aldlobd2u.asp
Just for reference.
Oh, and just as a refresher, my '95 is the one that works almost perfectly with EEHack. I can read/write/log with it perfectly. Every once in a while the logger will hiccup for unknown reasons and to be honest I'd be willing to blame the USB port on my laptop for that. The '94 is the one where EEHack threw constant errors and would fail to read. Never tried to write because of it.
Last edited by NomakeWan; 04-15-2020 at 08:16 AM.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
I checked the logs and it looks like the bus freeze at mode 08 bombardment and than resumes normal communication.
Can you try to give a 4-5 attempts burst than wait for silence, than again 5 attempts,than wait for silence. I think when the mode 8 went through at least 5 second silence can be observed.
What is the normal silence on end of message , can we use that to identify the end of messages, For example read byte to byte delay and when a pause longer than the expected 8192 baud is received the end of message can be flagged and the buffer dumped.
it does clear the buffer completely after sending that 'bombardment' (because we need to get rid of a lot of echos, and there's no point reading them). i think that's what the 'gap' you're seeing is. i don't think it ever stops. freezing the bus for a sec can't really be a bad thing.Originally Posted by kur4o
that is exactly how the old routine worked...but it didn't work on anything except an fbody.Can you try to give a 4-5 attempts burst than wait for silence, than again 5 attempts,than wait for silence. I think when the mode 8 went through at least 5 second silence can be observed.
the problem is the chance of those 'attempts' being timed properly and landing completely between that 9ms window is too low. there is just too much latency for it to work
i'm willing to try anything, but nothing i've done so far will let us send a message at exactly a time relative to the input. there seems to be just way too much latency. i want a different approach... this one that trust the OS to send a serial message at an exact time always results in someone not being able to use the software due to their interface and combination being different.What is the normal silence on end of message , can we use that to identify the end of messages, For example read byte to byte delay and when a pause longer than the expected 8192 baud is received the end of message can be flagged and the buffer dumped.
can you run eehack and get an 'idle traffic log'? it's in the raw command windowAs always if there's anything else at all I can do to help just lemme know--I will likely have more 94-95 Corvettes in the future, so I'd love to join your F-body flash party. :)
Yessir, see attached. "off" was taken with the key inserted but not moved, "on" was taken within a second of moving the key to the ignition on position, and the final log was taken after the car had "calmed down" a bit.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
I suspect there might be some protection on the bus conflict on a hardware level, and the bombardment might just be ignored and never reach the pcm. Than the aldl chip sends to cpu that bus is cleared and the processor start sending data again. A slightly more complex algorithm might wield better connectivity.
I have seen logs on the factory tools and the bus is always quieted on the first try. I guess it is a pure ftdi latency that is crapping the code you have done. The only thing that help is direct usb connection without any virtual comm ports, but that only can bring more problems and compatibility issues. I guess a true comm cable will work much better for that manner.
it works with fbody and bbody ecms, i think the window is just too tight for the entire message to land on a ybody where you have a window of less than 5 milliseconds to start sending the message.I suspect there might be some protection on the bus conflict on a hardware level, and the bombardment might just be ignored and never reach the pcm.
yeah i agree ditching the virtual com port would be helpful as would implementing a serial api with zero buffering, in fact FTDI has that, however that'd require all my users to totally uninstall their FTDI drivers and install one that only works with my tool.I have seen logs on the factory tools and the bus is always quieted on the first try. I guess it is a pure ftdi latency that is crapping the code you have done. The only thing that help is direct usb connection without any virtual comm ports, but that only can bring more problems and compatibility issues. I guess a true comm cable will work much better for that manner.
i have lots of experiments to run to solve this issue. i just wish i could spend time developing other parts of the program instead. i need this thing to connect to any aldl bus with even a shitty interface and i truly believe there is zero chance of doing that with timing
Once I tried the gm factory tool and it didn`t want to connect with y-body bin. I did some sniff scan and the tool was trying to send mode 8 to ccm, but never get a response. I remember it sends once on a connect time and than 4-5 more times with some interval like a second. I think getting bus master is pretty straightforward, than it is simple mode 8 request. The timing is real tight here I did some calculations and with 8192 baud a byte is send for 0.9765ms. So any pause above 1.5 ms will indicate the bus is not active.
I think that strategy is used by the factory tool, wait for some predefined time of silence. Not sure if it can be done here with ftdi.
Another problem with y-body is that communications is between 2 devices so you have a request from ccm and a response from a pcm. While b-body is simple pcm dumping data.
Once the request is send the pcm will likely respond no matter if a mode 8 is send. Even the pcm is not a master it can recieve mode 8 too and respond to it. So trying to shut up ccm and pcm at the same time might give some positive results.
yep i've pretty much called it 1ms for most purposes. so with an 8ms gap, you need to transmit in the first 4ms or it wont survive.The timing is real tight here I did some calculations and with 8192 baud a byte is send for 0.9765ms.
eehack does use a mode 8 request for bus keepalive or to check if the ecm is alive
this new tool is more procedural, it runs through an entire procedure without pausing, but before each packet it checks for up to 10ms to see if there's any crap in the buffer, and if there is, it tries to look for that bus master heartbeat packet thing again. so it's constantly checking to make sure it's still bus master
with an fbody, three requests 30ms apart always seem to land properly no matter when you start. garydoug that wrote scan9495 taught me that trick.
alright i have three methods i'm testing.
i'd love it if my two current test cases (nomakewan and sherlock) would test all three, i'll have them ready tonight in form of three buttons you can click, it'll tell us how long to connect, and how many attempts, then reset the bus master after, so you can try multiple attempts.
Posting Permissions
Reply With Quote
Bookmarks