NSFW wrote:Thanks! I'll have to learn a bit more about how J2534 works. Apparently it stops listening for log messages after sending the 'device present' message.
I don't think so, should continue just fine.
At least in UniversalPatcher it does, but it uses (modified) J2534Dotnet library...
j2534Device.cs, line 158 set device filter to priority 6C messages.
If you send TesterPresent with priority 8C, pcm start sending meesages using same priority and they get filtered out.
Add another filter with 8C or change testerpresent to use 6C
I think this should fix J2534 logging, but I can't confirm that myself. Joukoy, if you could try again I'd appreciate that very much!
I still need someone with an AVT to confirm that logging works with those devices.
with RC3, you should get a stern warning before your first write, but after you do a successful read or test write (or a real write) you'll just get a simple confirmation prompt before each write.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
I didn't see the replies here about changing the tool-present message from 8C to 6C until well after I posted RC3, but that's probably a better approach than what I tried.
I'll try that approach next, it would let me simplify some code elsewhere too.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
Another note, still in J2534Device.cs:
ReadVoltage() should be after ConnectToProtocol()
And in ReadVoltage(), row 398, should use ChannelID instead of DeviceID
Currently it works IF you have only one device in system (ChannelID = 0, DeviceID = 0)
But if DeviceID = 1 and ChannelID = 0, for example, ReadVoltage fails.
joukoy wrote:Another note, still in J2534Device.cs:
ReadVoltage() should be after ConnectToProtocol()
And in ReadVoltage(), row 398, should use ChannelID instead of DeviceID
Currently it works IF you have only one device in system (ChannelID = 0, DeviceID = 0)
But if DeviceID = 1 and ChannelID = 0, for example, ReadVoltage fails.
Voltage should be checked before opening a protocol. No point opening a protocol if you know battery voltage is 0v ect. PCMHammer doesn't do that check, but its an easy check to put in.
Once voltage is confirmed to be acceptable, only then should a protocol be opened.
Your assumption is for reading pins when connected to a protocol, When reading battery voltage, you pass the device id.
Please see below snipit as per J2534 document:
J2534ReadVoltage.PNG (26.02 KiB) Viewed 3242 times
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
joukoy wrote:Another note, still in J2534Device.cs:
ReadVoltage() should be after ConnectToProtocol()
And in ReadVoltage(), row 398, should use ChannelID instead of DeviceID
Currently it works IF you have only one device in system (ChannelID = 0, DeviceID = 0)
But if DeviceID = 1 and ChannelID = 0, for example, ReadVoltage fails.
Voltage should be checked before opening a protocol. No point opening a protocol if you know battery voltage is 0v ect. PCMHammer doesn't do that check, but its an easy check to put in.
Once voltage is confirmed to be acceptable, only then should a protocol be opened.
Your assumption is for reading pins when connected to a protocol, When reading battery voltage, you pass the device id.
Please see below snipit as per J2534 document:
J2534ReadVoltage.PNG
Ok, must be error in dotnet library. j2534-sharp uses DeviceID.
Thanks for correction.
