Flashhack - New LT1 flash tool

[steveo]

new version up, nothing big. 0.5.6

might work with P66 but please dont try it without sockets or if you're crazy.

it does proper ALDL keepalive now which will be helpful if you're doing any fun stuff with the manual commands, this should be better than EEHack for that stuff, if it's not then let me know and i'll keep working on it

there's a new setting that slows down request/response timing for if your bus sucks or have a bad serial interface

there are some more UI improvements too, the 'advanced' section works like it should.

trying to keep anything that would scare new users in the 'advanced' tab so you can't really do anything wrong. connection, disconnection, loading kernels, all that good stuff should be automatic so no need to expose those controls.

there's a 'disconnect' button now too that hands bus master back over and closes the interface, which should be handy

it handles EEB bins more gracefully now since our ESIDE recovery patch doesn't work on those. i don't know why you'd want to use an EEB bin but now you can with only a stern warning

enjoy or don't
you know where to find it

[NomakeWan]

Tested new version. New version's keep-alive routine causes the digital dash on my Corvettes to freak out every few seconds. Only other thing I noticed was that disconnecting from the bus doesn't hand serial comms back to ASR. I have to cycle the key to get that to happen.

[kur4o]

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.


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

I think the best way to keep the bus silent is to send broadcast message every 2 seconds stating that now the bus master is the tool[per ALDL spesc].
You can set the tool with F0 or F1 ID and just spam the bus with it.

something like this
F0 56 F1 [chksum]

[steveo]

Tested new version. New version's keep-alive routine causes the digital dash on my Corvettes to freak out every few seconds. Only other thing I noticed was that disconnecting from the bus doesn't hand serial comms back to ASR. I have to cycle the key to get that to happen.

i'm not sure what an ASR is, i thought since the CCM was bus master so we just have to hand control of the bus back to that

[steveo]

I think the best way to keep the bus silent is to send broadcast message every 2 seconds stating that now the bus master is the tool[per ALDL spesc].
You can set the tool with F0 or F1 ID and just spam the bus with it.

something like this
F0 56 F1 [chksum]

i thought some devices contributed to the idle traffic, wouldn't that possibly trigger onboard devices to produce bus traffic?

[steveo]

New version's keep-alive routine causes the digital dash on my Corvettes to freak out every few seconds.

can you be more specific about what it means when the dash 'freaks out'?

i'm not really sure how to prevent this and might need some more info. i'm only sending a request for nothing to nowhere, i'm not sure why it would respond to that by doing anything, and why wouldn't it respond similarly to other requests we're making?

can you test if a command like device F0 command F1 like kur4o said will make the dash freak out? (it'll time out, as there's no reply of course)

in practice, the keep-alive would never happen during a flash operation or any other continuous operation such as datalogging, so this is only really relevant for testing stuff

[NomakeWan]

https://youtu.be/xnQ098EvbHc

There’s a comparison of the two programs running and what the dash freaking out looks like. Flashhack has always done this on connect, but now it does it rapidly due to the keep-alive traffic. EEHack doesn’t do it.

On the ‘95 though (the car in the video) the ASR comes back online after disconnecting. So maybe the ‘94 is just being funky about it.

[steveo]

There’s a comparison of the two programs running and what the dash freaking out looks like. Flashhack has always done this on connect, but now it does it rapidly due to the keep-alive traffic. EEHack doesn’t do it.

the new version of eehack should be identical, i copied all the connection/disconnection/keepalive code over so this is quite confusing

You can set the tool with F0 or F1 ID and just spam the bus with it.

something like this
F0 56 F1 [chksum]

i've read an internal document that states that the F0 message is actually intended for the tester to ask if it's present before communicating (F0 is the ID of the aldl tester)

sending F0 56 F1 would be like telling ourselves that the CCM is the bus master
sending F0 56 F0 would be like telling ourselves that we are the bus master

i'm not sure either is correct protocol for a tester device to be throwing at the bus

have you seen a tech tool doing this?

still want to know how a device 0 message is affecting the dashboard. that's really weird.

[kur4o]

The norm is that the bus master spams its id every 2 seconds. When you take control of the bus, the tool becomes bus master and it should follow the norm if it doesn`t send any other data. I guess all should modules have built it F0 recognition as id.

The broadcast message having F0 as to ID might be targeted for the tool. You can give it a try with f0, I totally forgot that f1 was the ccm.

This message can be interpreted as tester device present, keep quiet.

[NomakeWan]

Okay!! So thanks to steveo pointing me in the right direction—I was confusing my bytes and bits, which is why I couldn’t pin down any specific commands for the CCM. Now that I’ve got the bits sorted, I’ve successfully gotten at least two commands working.

F10400040004 = Enable Control of Rear Defrost, Activate Rear Defrost
F10400020002 = Enable Control of Horn Relay, Activate Horn Relay

So kur4o had it right; the first two bytes are for enabling control, and the second two bytes are for executing commands. That’s why if the first four entries are 0000 then nothing happens if you put stuff after it; you’re telling the CCM that you don’t want control of any devices, but that you want devices you don’t control to perform tasks. That won’t work.

So now that I’m on the right track, I’ll do some more testing to try to pin down which bit belongs to which device. I can’t do it today but I’ll try to get it done soon.

[sherlock9c1]

Now you're really getting somewhere. You could have the PCM automatically activate rear defrost if engine coolant temp is below 50F. And then have the horn activate as a shift "light" once a certain RPM is reached. Sweet.

[steveo]

can i honk S-O-S if your reflash fails
that would be really sweet

[steveo]

https://youtu.be/xnQ098EvbHc

There’s a comparison of the two programs running and what the dash freaking out looks like. Flashhack has always done this on connect, but now it does it rapidly due to the keep-alive traffic. EEHack doesn’t do it.

On the ‘95 though (the car in the video) the ASR comes back online after disconnecting. So maybe the ‘94 is just being funky about it.

so i finally watched your video with sound and paid attention, thanks for doing that video

one thing i noticed is that it's actually reconnecting to the bus constantly, that's not normal, the keepalive should just be silent

something is actually responding to my new keepalive request on the bus. can you get me a comms log of that? it could help me figure out what's going on there.

[NomakeWan]

I know I said I wouldn't be able to do it today, but I actually found some time and mapped out what I could. There are still some unknowns, but the major functions are there. Here's the commands.

F1 04 8000 8000 Door Ajar
F1 04 4000 4000 Low Oil
F1 04 2000 2000 High Beam 100% Brightness
F1 04 2000 0000 High Beam 60% Brightness
F1 04 1000 0000 Delayed Accessory Bus Relay Off
F1 04 0800 0800 Security
F1 04 0400 0400 Seatbelt
F1 04 0200 0200 Check Gauges
F1 04 0100 0100 Change Oil

F1 04 0080 0000 VATS Fuel Enable Off
F1 04 0040 0040 Fast Chime
F1 04 0020 0020 Slow Chime
F1 04 0060 0060 Both Chime
F1 04 0010 0000 Starter Relay Off
F1 04 0008 0008 Courtesy Lights
F1 04 0004 0004 Rear Defrost
F1 04 0002 0002 Horn
F1 04 0001 0000 Blank Digital Dash

As before, these are just bits. So it's bit 0~7 being set to either 0 or 1. The first two bytes determine what all you want to control, and the second two bytes set the state of that control.

EDIT: After doing a little digging and some more testing I now have filled in the remaining unknowns. The Delayed Accessory Bus Relay was hard to figure out until I thought to try it while turning the car off with the radio on. Sure enough the radio immediately shut off as soon as the key turned off, rather than staying on like it normally does until the door is opened. The VATS Fuel Enable and Starter Relay I tested by setting the bits to 0, then trying to start the car. If the Starter Relay is disabled, absolutely nothing happens. If only the VATS Fuel Enable is disabled, it takes much longer to start, but it does start once oil pressure comes up (because on the Corvette, the fuel pump circuit is wired directly to the oil pressure switch in case the relay circuit fails).

[NomakeWan]

so i finally watched your video with sound and paid attention, thanks for doing that video

one thing i noticed is that it's actually reconnecting to the bus constantly, that's not normal, the keepalive should just be silent

something is actually responding to my new keepalive request on the bus. can you get me a comms log of that? it could help me figure out what's going on there.

Sure thing, see attached. Interestingly while the keepalive continues after rebooting the PCM, the digital dash isn't freaking out, and the "Service ASR" light goes out. It's only while the kernel is loaded and nothing it happening that the digital dash freaks out and the Service ASR is on.