im not convinced your ‘94 is a good test subject
how about the ‘95?
Printable View
im not convinced your ‘94 is a good test subject
how about the ‘95?
actually i reviewed the log and i know what's wrong here. i'll release a fix tonight.
The thing is, 0.5.1 actually worked pretty much perfectly even on my '94. It had an occasional initial connection issue, but once it was connected it could read without major issues and could disconnect and reboot the PCM gracefully. So while I absolutely agree that the '94 has some other issue that's making this a major PITA for all involved, that's kind of the whole point.
Once I get back from work I can yank the CCM fuse just to see what happens, sure.
I also received my Saleae Logic 8 the other day, so I can now do snooping on the ALDL bus while communication is going on. I do need to get my other laptop out of storage to do it though--can't run the data acquisition software on the same machine that's talking to the bus because there's a fairly good chance I'll run out of CPU cycles on the poor little netbook, hahaha. No big, I should be able to work that out tonight.
Sweet! I look forward to testing the new one.
I always test on the '94 first because it's the problem child, and because it's in the garage. If the idea is to have a robust flash program, I know that the '94 will be the real test to see if it works. The '95 is great as a control just to see if everything works the same way, but yeah.
ok this problem has been bothering me day and night but the universe wants me to win.
i was driving around and found some dude with a 95 vette acting like a chump smoking his tires and whatever, so i ran him off the road with my jeep and confronted him.
i managed to lure him to my house with beer and the promise of a free tune.
i somehow convinced him i was going to secretly supercharge his car with my computer.... (i did nothing...)
i managed to simultaneously 'scope and log flashhack with one of those horrible CCM devices, trying lots of iterations with various serial latency settings.
i threw the last algorithm out.
the new one should be a win.
0.5.3 tested fine on my bench harness with a B-body tune. I'll email you a log in case you're interested.
this works for me with a vette with 1ms, 3ms, and 16ms latency.
works on the bench with a b-body bin with 1ms, 3ms, and 16ms latency.
works in a ybody with a b-body bin with 1ms, 3ms, and 16ms latency.
works on the bench with an b-body bin with 1ms, 3ms, and 16ms latency.
works on the bench with an f-body bin with 1ms, 3ms, and 16ms latency.
basically if this doesn't work your car must be broken.
i did have a fun thing where my laptop freezes at 1ms latency with this ftdi interface sometimes, just like someone earlier in this thread noted. it's totally a driver issue. flashhack wasn't even open at the time. maybe changing the latency warrants a reboot ?
oh yeah here's the file
http://fbodytech.com/download/1269/
no need for the whole log,
: Found heartbeat, sending mode 8 request with predelay (x)
what's the greatest value of x before it connects?
for anyone testing, the advanced tab DBG_B button is a good way to test just connection, it sends a single datalog packet request so you'll know if the routine works without much reprogramming drama.
Apologies for the delay in reporting back--got caught up in some real life stuff. Anyway I tested out b0.5.3 and it was a resounding success on both cars. Had no trouble connecting and staying connected to the '94, and absolutely no problem whatsoever on the '95. Even bothered to load and unload kernels several times just for good measure, and downloaded the BINs from both cars too. Looks great!
The greatest value of predelay on the both cars is 1, and that's only on initial connection. Subsequent connection attempts (such as clicking "unload kernel" after "load kernel") result in a predelay of 0.
Woohoo! Cheers to some rando on the street with a Corvette, and congratulations on slaying this dragon, steveo!!
my test bench ecm is about to die, which is awesome, it survived fire and abuse and pulling and prying and drunken mischief for the entire duration of making this flash tool. if it died tomorrow i think we're in a good position to continue other work and just have me make small improvements that don't really require in house testing.
so far the new connection code is looking good too, no reports of slow or unstable connections from the very few brave people that are testing this thing.
but there's been a weird bug come up a few times, though, i noticed it once during testing and it never happened again so i figured it was just an odd serial nose thing..but kur4o says it hit him a few times too.
everything looks good, the bus is silent, then we go to make our first command, and there is no serial echo (usually by the time the write is complete, the echo is pretty much waiting in the buffer for us...). then reply comes back ages later with the echo with our next command reply, like a massive lag time, and screws our next command up. it's really intermittent and only seems to happen after we've recently connected to the bus so i doubt it would happen mid-procedure, it's like some oddball leftover buffer issue from the connection algorithm.
just in case it's a real thing, i've gone ahead dropped a new version and increased the time we wait for a serial echo quite a bit, and re-enabled the code that requires the serial echo to be valid to proceed after initial connection, which gives us a larger bucket to try to snag any erroneous bytes from a bus master device waking up out of nowhere (...like corvettes or whatever) but also allows some retry logic to overcome this intermittent bug if it comes up.
as the bug makes no sense and i can't find a real cause, i'm sure this will squish it, but if anyone sees it happening....let me know ?
i think kur4o and i have almost managed to figure out how to make the P66 v6 work properly, which opens up a whole new user base... as usual he's trying to help by making it more awesome than it needs to be, so we'll be waiting a bit for that. i think he's planning to test write it with his bench ecm with no sockets, so i really hope my ameture code doesn't eat the poor thing alive.
then i'll be getting a few prototypes of these in the mail very soon: https://obdxpro.com/
.. and will start work implementing some 96+ VPW ecms.
i'll be the third tool to the party as pcmhammer and LSDroid are functional but i think having another option will be cool, and i don't plan to share or even really look at any of their code base because what's the fun in that!?
Tested the new version just to make sure nothing broke,and sure enough nothing did. Sweet! I also bothered to check the times between my two cars. It takes 3 minutes and 7 seconds to read my '95, and 3 minutes 37 seconds to read the '94. So an extra 30 seconds just for the bus being noisy. However this doesn't affect the outcome whatsoever--communications errors and checksum failures appear to be a thing of the past.
I'm super excited to hear that you're planning on working to support the 96-97 LT1/LT4 PCMs. I doubt I'll ever be lucky enough to find a reasonably-priced '96 Corvette, but if I am, it sure would be amazing to be able to use your software rather than go through the trouble of converting to the '95 PCM.
Looking forward to it!
it's crazy there's a time difference.... is there a long connection time with the '94? are there any read checksum errors in the comm log, and is it recovering properly from them? (it should but actually i've tested write waaaaay more than read)
The connection time isn't that different between the two. It's that during the read it occasionally hits an incorrect response, retransmits, then gets the correct response. Or as Flashhack puts it, it times out waiting for the response and tries again. It does this incredibly gracefully and the end result is a successful read.
Here's what one of those "pauses" in the read looks like:
20.695: COMM::Sent message: F45C060200200B390044
21.705: COMM::Packet error: Timeout waiting for reply payload.
21.705: Trying to reconnect to bus...
21.988: COMM::Sent message: F45C060200200B390044
22.167: COMM::Recieved reply: F4D906AA390076747080808080808080808080808080808080 8080808080808080808080808080808080801A40FF401A8080 80805858585858585858585858585880808080808080808080 80808080808080808080808080808080808080808080808080 808080D0D0D0D0D0D0D0D0D0D0D0D0D0808080808080808080 80808080808080808035
22.167: DEBUG::Read TSIDE3900[80]
I should note that WinFlash also took longer to flash/read the '94 than the '95, likely for the same reason Flashhack does. That's why I don't consider it a problem as long as Flashhack is handling it gracefully, which it is.
ah cool that's kind of what i wanted to see
i've simulated similar stuff just unplugging and reconnecting the aldl cable at random during a write but never really bothered to check read..
if it happens during an erase sometimes it's okay and keeps going, and sometimes you have to hit 'write' again. depends when and for how long it dies.
most operations retry a decent amount of times before failure but i've cut that number back in later versions, because if something insane is going on, sometimes you have to accept catastrophe and just restart the procedure clean to win, and now that it's possible to do that at any point during a write, sometimes it's worth it to just bail.
First off - thank you to steveo and all those working on developing and testing flashhack!
Been doing some testing of b0.5.4 with good results on a 95 B-body (9C1) and 95 F-body (TA).
Tested Dbg_B, loaded/unloaded kernels as well as full reads. Tested with 16ms, 3ms, and 1ms latency.
Max predelay was 2. All kernel unload tests and full reads on both B and F cars consistently showed a timeout waiting for reply payload during T-side reboot, but b0.5.4 caught it and continued to completion. I pasted a typical comm below - very similar to that of NomakeWan's post above.
35.240: Rebooting TSIDE
35.242: DEBUG::Executing prepared program REBOOT on TSIDE
35.255: COMM::Sent message: F4700602003C30CC06AAED00C6029D1438CE01FF6F000926FB 6F0020FE1A
36.301: COMM::Packet error: Timeout waiting for reply payload.
36.304: Trying to reconnect to bus...
36.583: COMM::Sent message: F4700602003C30CC06AAED00C6029D1438CE01FF6F000926FB 6F0020FE1A
36.637: COMM::Recieved reply: F45706AA05
36.639: DEBUG::Executed REBOOT on TSIDE
36.641: Rebooted TSIDE
With regard to echoes, I had done some earlier test reads using b0.5.1 and saw something similar, but attributed it to using the default 16ms latency. It occurred on both the B and F cars when entering programming mode; T-side (B-body) and E-side (F-body). These errors caused b0.5.1 to hang at that point without an obvious path forward. Here are the tail ends of the comms:
B-body:
55.068: COMM::Sent message: F45608AE
55.352: Successfully connected to the ALDL bus.
55.353: COMM::Sent message: F45605B1
55.368: COMM::Timeout waiting for read of size 4
55.368: COMM::Recieved reply: F45605B1F4580D023372
55.369: DEBUG::Unknown response when entering programming mode.
55.369: ERROR! Could not connect or load the kernel.
F-body:
61.400: Entering programming mode on ESIDE
61.413: COMM::Sent message: E45605C1
61.429: COMM::Timeout waiting for read of size 4
61.431: COMM::Recieved reply: E45605C1E4580D023382
61.432: DEBUG::Unknown response when entering programming mode.
61.433: ERROR! Could not connect or load the kernel.
I hope these results are helpful -
Jim
yep that’s the bug i was just talking about. i would expect it to be gone now.
the error on reboot is fine, one of those acceptable errors. ive been ignoring it since the reboot always seems to succeed whether it has a valid response or not. its possible that im not waiting long enough for the reply though
hey nomakewan aka mr. ccm,
can you do some testing for me for fun?
there is a 'send raw command' in flashhack's advanced tab.* connection should be automatic if your CCM has woken up. the output shows up in the debug log.
the first field is the device, so set it to F1
second field is the command
third field (long) is the rest of the message
can you try the following commands/payloads to see what commands it supports or if it responds at all, the payloads should cause the command to fail but then we'll know the command exists:
03, 2000 (read 64 bytes starting at 0x2000)
03, 0200 (read 64 bytes starting at 0x0200)
04, 0000 (test actuator)
05 (empty) (enter program mode.* dont worry, it'll ask for a key with 0D if this works, we just wont give it one)
0C (empty) (program aux eeprom)
in particular if the mode 3 command works we can dump the rom which could yield some fun stuff. if it supports mode 5 we might be able to flash it ourselves one day.
Sure thing. Here are the results of my testing. First section was using EEHack's manual command, followed by flashhack's.
Code:TX+F15803200094
RX+F1570300B5
TX+F158030200B2
RX+F1570300B5
TX+F158040000B3
RX+F15604B5
TX+F15605B4
RX+F1570500B3
TX+F1560CAD
RX+NO REPLY
COMM::Sent message: F15803200094
COMM::Recieved reply: F1570300B5
DEBUG::Got reply to command: DEVICE=F1 COMMAND=3 DATA=00
DEBUG::Sending raw command: DEVICE=F1 COMMAND=3 DATA=0200
COMM::Sent message: F158030200B2
COMM::Recieved reply: F1570300B5
DEBUG::Got reply to command: DEVICE=F1 COMMAND=3 DATA=00
DEBUG::Sending raw command: DEVICE=F1 COMMAND=4 DATA=0000
Reconnecting to ALDL bus, please wait....
Listening for ALDL heartbeat to determine current bus master...
Got heartbeat frame for current master f1
Silencing bus master device f1
DEBUG::Found heartbeat, sending mode 8 request with predelay 0
COMM::Sent message: F15608B1
DEBUG::Found heartbeat, sending mode 8 request with predelay 1
COMM::Sent message: F15608B1
COMM::Exceeded minumum silence length, connection is likely.
Successfully connected to the ALDL bus.
COMM::Sent message: F158040000B3
COMM::Recieved reply: F15604B5
DEBUG::Got reply to command: DEVICE=F1 COMMAND=4 DATA=
DEBUG::Sending raw command: DEVICE=F1 COMMAND=5 DATA=
COMM::Sent message: F15605B4
COMM::Recieved reply: F1570500B3
DEBUG::Got reply to command: DEVICE=F1 COMMAND=5 DATA=00
DEBUG::Sending raw command: DEVICE=F1 COMMAND=C DATA=
Reconnecting to ALDL bus, please wait....
Listening for ALDL heartbeat to determine current bus master...
Got heartbeat frame for current master f1
Silencing bus master device f1
DEBUG::Found heartbeat, sending mode 8 request with predelay 0
COMM::Sent message: F15608B1
DEBUG::Found heartbeat, sending mode 8 request with predelay 1
COMM::Sent message: F15608B1
COMM::Exceeded minumum silence length, connection is likely.
Successfully connected to the ALDL bus.
COMM::Sent message: F1560CAD
COMM::Packet error: Timeout waiting for reply payload.
Trying to reconnect to bus...
COMM::Sent message: F1560CAD
COMM::Packet error: Timeout waiting for reply payload.
Trying to reconnect to bus...
COMM::Sent message: F1560CAD
COMM::Packet error: Timeout waiting for reply payload.
Trying to reconnect to bus...
COMM::Sent message: F1560CAD
COMM::Packet error: Timeout waiting for reply payload.
Trying to reconnect to bus...
ERROR! Raw command not successful: DEVICE=F1 COMMAND=C DATA=
ok cool thanks
i screwed up and the first commands should have been mode 2 (read 64 byte chunk) but if it does mode 3 (read single address) it probably does mode 2 as well.
i'll write you a thing to dump the CCM rom with mode 2 so we can try to see if there's anything cool in there or at least have it for reference, maybe get both the 94 and 95 so we can compare? i haven't seen a CCM bin floating around so it could come in handy.
if mode 5 responds that means we could probably reprogram it but who knows. the mode 4 commands its supports we might be able to find pretty quick once we have that rom.
Sure! I'd be more than happy to dump both cars, anything ya need. Would be pretty cool to be able to get more of the modules on the car to respond to open-source tools.
did two fun things tonight for the next version
made the connection code faster, there's a checkbox in configuration that will speed up interfaces that are known not to be awful and are fairly low latency. it's off by default because flash tools need safe defaults.
it also has some learning capability now, regarding the preemption delay factor, so if it always tends to connect with 2ms of preemption, that's the first thing it'll try next time to avoid too much initial guessing. if it has a high preempt value it'll tend towards allowing it to reduce (since it might just be a fluke it took so long that one time). it should speed up most connections without slowing down many.
the mode 2 based sequential memory dump is done and it behaves kind of like a regular flash read but with no kernel, in fact it's almost better at reading the tside than the real flash routine which is kind of embarrassing considering all the extra work we've done. it's super primitive and doesn't do any region pre-mapping. it'll be nice to have. it should dump the rom for *anything* that supports mode 2 including the earlier non-flash capable ECMs in case anyone wants to do that.
if you want to dump the ccm just use M2 read device in the advanced tab with device F1, i think it'll work. you can leave the size alone since we don't know how much ram the CCM has. if it crashes the CCM or something dumb like that it'll still save the bin. don't worry it's entirely safe.
i'll have it up on the internets in a sec
edit: okey dokey, 5.5 is up there, give it a shot
Okay! Had a chance to test it out. I'm pleased to report that the read routine for the CCM worked on both cars, and I've attached both the BINs and logs to this post.
I'm also pleased to report that on default settings, the new version of flashhack reduced the read time on my '95 from 3 minutes 7 seconds to 2 minutes 51 seconds. A whole 16 seconds faster, not bad at all. I can't currently test the '94 because it's a little low on charge and I loaned my tender out to a friend. It's about time to take her out of the garage to stretch her legs, though, so once she's had a good drive to charge the battery I'll try it again and see if it had any improvement too.
that's awesome that it worked. a first run disassembly revealed a few familiar routines. i doubt i'll have much time to work those over but they might be worth having a look at one day.
the 94 and 95 are different enough in the program region where i think the main program had a pretty decent sized rewrite between those years, it doesn't just seem like some configuration changed.
i can't imagine reflashing the ccm would have any real benefit but maybe we can find some cool tricks and exploit them just for fun. to be honest i don't know what the CCM even really does.
i'm glad we can read arbitrary gm device code, i wonder if there are any other devices around we could dump roms on
I looked at the 2 files and they seem to have 32kb rom, eprom or external flash. 95 having some extra code at the end. Pretty similar though.
There is 100 bytes ram on the processor and some ram mapped at 6000 area.
I looked at the comm code but too far from anything. You can upload code and execute for sure.
I know these ccms are very expensive to rebuilt and some needs vin and engine code set up to run correctly.
Now that mode2 for random device is awesome idea. You might expand it to specify a custom ID[f1,f4,e4,f9 and so on] to run it on other modules.
Master is not always the target.
it will work on anything that supports mode 2..Quote:
Now that mode2 for random device is awesome idea. You might expand it to specify a custom ID[f1,f4,e4,f9 and so on] to run it on other modules.
Master is not always the target.
you specify a device ID in hex and a maximum read size and press go.
in fact the way that flashhack is designed, the flash processor doesn't know or care what the master device is. it just says 'make this request' and the interface layer makes sure that we have control over the bus before it sends it.
give it a try
well my test bench ecm 8051 ECM is finally done
the ESIDE just stopped booting out of nowhere. i have verified with a chip reader the bin that's on it is perfect, so obviously the re-socketing and torch abuse and constant chip removal-install has created some kind of connection fault that i can't trace.
last time this happened i reflowed the socket and it came back to life, but not anymore. luckily i think it served its purpose and the EE flash tool is as good as its going to get with maybe the odd bug fix here and there. i can start working on other ECMs.
R.I.P.
in other news certain bins have refused to install the recovery patch just on the e-side, if this happens it will complain, the fix is to just go to the parameters and disable that recovery rom patch for now. it'll still be 100x safer than any other flash tool assuming nobody comes and turns your key off during flashing.
i'll try to figure out why it's happening and fix it for future releases.
nomakewan if you want to have some totally useless fun, you should do some mode 4 brute force testing on the CCM.
device F1
command 04
now try random stuff in the payload... 02, or 00cc... or 0000C0
see if any of the bytes manage to get a response with your dashboard or whatever
maybe we'll stumble upon something that blinks a light or displays something
again totally useless but fun to try
I'm not sure about just randomly throwing code at it, but you're correct that it should be able to do that. I have confidence in that since Vertronix's manual for the Tech 1A includes Mode 04 commands for the CCM.
Tech 1A Body Commands: http://www.zr1netregistry.com/Portal...01988-2004.pdf
Tech 1A Chassis Commands: http://www.zr1netregistry.com/Portal...6-2004view.pdf
I might give it a whirl just for shits and giggles anyway, though I imagine accidentally triggering the horn relay on might get exciting. :yikes:
none of those look too dangerous. i wonder if 0xFFFFFFFFF turns them all on at once. if you could find the horn enable bit we could definitely have some fun with that one. keep in mind with a mode 4 command, everywhere i've seen them, sending a few zeros as the payload usually cancels the whole thing (and so does cycling the key obviously)
Just a quick update -
Flashing to F-body had no issues using b0.5.4 at 16ms, 3ms, and 1ms latency.
Performed full writes to both sides. No echo-related bugs have reappeared in any of the reads or writes using b0.5.4.
Still have to test on B-body.
Downloaded b0.5.5, but haven't done any testing yet.
Steveo, sorry to hear that the 8051 is done for - LT1s seem to be in good shape though.
And excited to see you're looking at the 96+ LT1 pcms!
Jim
thanks for testing!
i'm very confident that the flash tool for the lt1 isn't just the best lt1 flash tool but probably one of the best flash tools period as far as recovery goes. that recovery patch kur4o came up with is barely even necessary, since ECM power failure during a flash is pretty hard to induce, but is icing on the cake.
right now we are at bricked ecm count zero and i think we'll stay that way, i don't see how it'll brick an ECM unless some total moron unplugs ECM power during an erase or after a failure occurs.
0.5.4+ was tested in a loop for 24 hours solid and had zero errors
one thing that's come up is the rare $EEB mask, due to differences in the comms code, the e-side recovery patch doesn't work (and i dont care because its so rare) but flashhack's logic does catch the problem and refuse to install the patch rather than screwing something up. you have to go disable the patch for the e-side. flashing still works and recovery still works if ecm power is maintained (and the t-side recovers fully) so i'll leave that as-is.
edit: i will put this connection code in eehack's next release (which will also hide or remove the flash tool in eehack itself, directing people to use this much safer one)
LOL
Okay, so first off, it's actually hard to use Flashhack to interrogate the Mode 04 commands for the CCM. This is because the communication routine in Flashhack causes the digital dash to freak out anyway on successful connection, so it's hard to tell what's from the command you just sent and what's just a result of the bus going into serial data deprivation mode. Sending FFFF, from what I could tell, did cause the high beam indicator to come on (though my headlights were down, so I couldn't tell if this was just the indicator or also the lights; judging by the wiring diagram it should just be the indicator). I didn't notice any others but I'm not sure. So after finding it hard to tell the difference between the command I sent and the connection routine resetting the digital dash, I decided to send FFFFFFFF.
This was a massive mistake, as as I should have expected, it caused everything to come on all at once, including the horn relay. These all stayed on for about five seconds before the CCM reset to normal mode. I also was reminded the hard way that the CCM is on battery power, not ignition power, because turning the key off did not stop the horn from blaring. :yikes:
i can't believe we honked your horn via the aldl port. that's some really great pre-canbus stuff.
flashhack 0.6:
- made horn honk at random during flash write. only affects corvette owners
Definitely going to stick to 0.55, HAHAHA.
Tomorrow if I have some time during the day (somewhere other than my driveway), I'll try using EEHack to do the test so I can keep the dash up, and see if I can figure out which bit goes to which operation. Would be pretty hilarious if it really was just based on their position in the list from the service manual.
i'd like to know why eehack and flashhack work differently with regards to your dash, can you look into it? things should pretty much be identical from the perspective of the dash, especially with the new connection logic that doesn't disturb the bus too much
I'll look into it. I haven't gotten my second laptop set up yet so I can't do signal analysis just yet, but I plan on being able to do that this weekend. But yes, the latest version of EEHack does not interfere with the dash (except of course for nullifying the MPG calculations), but Flashhack causes the dash to reset upon successful connection (security light comes on, digital displays SYS, then it wakes back up).
I did some more experimenting with EEHack and the CCM in a parking garage today at work. It turned out that the five seconds I was experiencing while experimenting with Flashhack was actually due to Flashhack's timeout period. So with Flashhack, if I send a command, it first connects to the bus, then sends the command, then after a certain amount of time (~5 seconds?) with no further commands, it disconnects from the bus and returns everything to normal operation. This disconnection process resets the CCM, which cancels the Mode 04 command. EEHack on the other hand connects first and stays connected until you disconnect it. As such, sending a command will cause that to continue to run until you send an opposing command (such as 00) or reset the CCM or the bus.
So, the results of my experimentation were...interesting. I haven't pinned down how to exactly get what I want out of the Mode 04 commands. But here's what I was playing with.
First, 00 does reset Mode 04, so you can turn things back off that you turned on. That's important, especially if you turn the horn relay on with EEHack. Here are the commands I was able to try out:
FF = High Beam Indicator/Relay? Again, had the headlights down, so not sure if it's just the light or if it's also the high beams themselves. You do hear a fairly loud relay click when this comes on.
00FF = Dim Speedometer. This causes the digital portion of the dash to blank out.
FF00FF = Security, Change Oil, Door Ajar, High Beam, Check Gauges, Seatbelt, Low Oil. This essentially causes every light on the dash to come on (except the turn signal indicators), as well as the Low Oil light on the DIC.
F000F0F0 = Door Ajar, High Beam, Low Oil.
00FF00FF = Dim Speedometer, Courtesy Lights On, Chime On, Horn Relay On.
00FF00F0 = Dim Speedometer, Chime On.
Interestingly, attempting to do something like "000000FF" does nothing. It seems that if the first four bits are 0, nothing happens. At least one of the first four bits must be nonzero. I only tested F, but considering the combinations of lights that came on, I'm guessing that this is actually based on number values somehow.
flashhack doesn't really have a timeout period. eehack does have a keep-alive feature that keeps twiddling the bus keep it asleep. what's happening is the CCM times out with no activity on the bus in flashhack and resuming normal traffic. i might add a keepalive thing to help with testing like this but as a flash tool it's probably not necessary, we just start our operation, and when it's done, it's done. there should be no idle time.Quote:
I did some more experimenting with EEHack and the CCM in a parking garage today at work. It turned out that the five seconds I was experiencing while experimenting with Flashhack was actually due to Flashhack's timeout period. So with Flashhack, if I send a command, it first connects to the bus, then sends the command, then after a certain amount of time (~5 seconds?) with no further commands, it disconnects from the bus and returns everything to normal operation. This disconnection process resets the CCM, which cancels the Mode 04 command. EEHack on the other hand connects first and stays connected until you disconnect it. As such, sending a command will cause that to continue to run until you send an opposing command (such as 00) or reset the CCM or the bus.
ah yeah that's something we've seen before. sometimes there's bits/bytes for 'enable override' then bits/bytes for 'on/off'.Quote:
Interestingly, attempting to do something like "000000FF" does nothing. It seems that if the first four bits are 0, nothing happens. At least one of the first four bits must be nonzero. I only tested F, but considering the combinations of lights that came on, I'm guessing that this is actually based on number values somehow.
this is because overriding a control system switch is actually a tri-state. it can't just be on/off, it's actually on/off/normal (i write on/off/auto in eehack)
when eehack is running, enable that advanced mode thing that shows the hex at the bottom of the screen, you'll see how some actuators require multiple bits in combination to work this kind of thing.
It is usual 1 bit to enable control of the solenoid and a second bit to turn on/off.
You can try 00000101 00000202 00000404 00000808 00001010 00002020 00004040 00008080
and so on
On PWM output one bit enables it and the a second byte defines the range. I am sure there is more left on the table than you have in the list.
I tried to find the commands in the bin but I am still nowhere near to that.
my 8051 test bench is working again.....for now.
None of those work. As I thought, if the first four bits are 0, then nothing works. So nothing that starts with 0000 will get you any response.
That said, here are the results of today's testing. I still wasn't able to really pin down individual commands, nor how exactly individual things were queried. But looking at it, there does appear to be a firm numerical component rather than just "[device][state]" like "1F". So I'm going with my original theory that the actual output value in decimal form is relevant to the command(s) performed, rather than individual bits representing which command is done and on/off.
Oh, and I popped the headlights up, and confirmed that the high beam light is just the indicator, not the actual high beams.Code:1F (Relay under steering wheel clicks)
2F (High Beam Indicator On dim)
3F (Same as 2F)
4F (Nothing?)
5F (Same as 1F; Click that interferes with radio; Radio Dim?)
6F (Same as 2F)
7F (Same as 1F)
8F (Nothing?)
001F (Speedo Dim)
002F (Same as 001F)
003F (Same as 001F)
004F (Same as 001F)...
F0F01F00 (Same as 2F)
F0F02F00 (relay clicks, high beam light brighter, radio interference)
F0F03F00 (high beam bright)
F0F04F00 (hi beam dim, click, low oil)
F0F05F00 (hi beam dim, low oil)
F0F06F00 (same as F0F04F00)
F0F0F01F (hi beam bright, door ajar, low oil)
F0F0F02F (door ajar, hi beam bright, low oil, slow chime)
F0F0F03F (same as F0F0F02F)
F0F0F04F (door ajar, hi beam bright, low oil, fast chime)
F0F0F05F (same as F0F0F04F)
F0F0F06F (door ajar, hi beam bright, low oil, faster chime) (faster chime = both chimes??)
FFF0F0F0 (same as F0F0F06F!?)
FFF1F0F0 (same as above but with speedo dim)
FFF1F1F0 (same as above but with Change Oil)
FFFFFFF0 (same as above but with seatbelt)
0F0F1F11 (security, change oil, seatbelt)
0F0F1F12 (same as above, with speedo dim and horn)
0F0F1112 (same as above??)
i did some research and found the most efficient way to keep the ALDL bus alive is to send a valid message to a nonexistant device.
conventionally, we would 'silence the master device' over and over, since the device wont wake back up if there's ALDL traffic.
one problem with that is the device may be gone, or be unable to reply as it's running a kernel incapable of that. so we have to wait for that reply, because if it comes while we're sending a message, it'll be corrupted, forcing a reasonably long delay between keepalives and requests.
i tried just sending zeros for a keepalive, but it *seems* like it needs to be a valid message which passes checksum verification, and is obviously ignored as it's from a nonexistant device.
so if you just send a valid mode 0 request to device 0 or some other nonexistent device every few idle seconds that works