pcmhacking.net

Tazzi wrote:

rolls wrote: Yep at the CAN level there is no defined behaviour, you can listen, write crap and do whatever you want. J2534 is a higher level wrapper over the top and it expects to be the only "tester" on the network. You can connect with flow control disabled (eg no 7E0 response) and CAN selected however J2534 then automatically filters all ISO15765 packets.

Yep yep, that makes sense. The device must send tester present constantly on the network (or similar).. so two devices would freak each other out. That would be why the devs added that extra sniffing ability then.
Guess theres perks of both systems.. J2534 is structured throughout making it easy(ish) to support other J2534 devices.. but at CAN level it gives raw access.

Yep. Considering what I am doing raw CAN access would be fine as most CAN projects out there offer filtering at the cable level anyway, none of them offer variable voltage injection onto pins though. For now J2534 is really the only method I can use.

I also just implemented a "tester present" loop in my program that runs in another thread and made my J2534 library thread safe. Now if you enter security access and the user is prompted with a message it doesn't time out the security access if they take more than 1 second to press yes/no.

Should have something out tonight for people to play with. It now can read unpacked or packed binary files, eg a 1.4mb or 6mb BA bin with real offsets. It will also compare the file to the PCM you are downloading to to see if the VIN/strategy or PCM type doesn't match. I won't add in any editing capabilities though, all that stuff will be in the editor flashing program. This winforms program will just be for engineering type stuff like logging DMR, sniffing and flash read/write.

MeZmeriZe wrote:Happy to help any way I can.. I've been working my way though howto's on dotnet, reverse engineering with IDA and reverse engineering PCM's.. lots of reading.. Then I had to port a two stroke and got distracted for a bit.

Then I discovered PerlNet http://docs.activestate.com/pdk/6.0/Per ... rview.html and thought.. ohhhhh.. I could be using perl code with dotnet libs.. I'm far far more at home with Perl than C# and it has some possibilities.. not the least of which is that Perl compiles down to Microsoft IL. And then there is this: http://search.cpan.org/dist/Win32-CLR/lib/Win32/CLR.pm

probably I should just learn C# but for trail and error and test stuff Perl has always been my go to girl.

Just saw the above. Personally my opinion is use the correct tool for the job. If your program is all regex/html parsing etc then perl is the way to go and stick with a perl console app. If you want to quickly script a console app with http/serial etc use python. If you want a GUI throw perl in the bin and write a proper .NET or C++ program with wxwidgets etc.

I have actually done the reverse before with embedding a perl script into a C# program. The script was for porting oldschool html help files to media wiki markup (about 400,000 help files for a gov project). I used a perl html converter and the awesome perl regex to build tables/replace fonts etc. The C# program then made a threaded program to bulk convert and upload to the wiki site running the perl code it its own container.

Ran into a nasty Pinvokestackimbalanced problem with calling the J2534 dll, seems to occur randomly. If i run the program in the debugger I have no issues at all but debug/release mode it doesn't work.

Basically as a result I can't catch any exceptions and the program randomly crashes.

This will be fun to figure out.

Found the problem and learnt a bit about threading.

Turns out if you create an object instance in your UI thread, then pass that object into a worker thread and it creates an exception, even though you put a try catch the exception is generated on the UI thread, not the worker thread that was doing work with it.

The other annoying thing is if you run this logic in debug mode in VS it passes the exception back via some magic so it all appears to work, it is just when you run it without a debugger attached that it fails.

Burnt about 4 hours on this so probably won't send out an update until next weekend as I don't have any more time.

Bummer.

Ok I was wrong, it is a stack cookie based corruption with the J2534 dll when I run without the debugger attached. Absolutely no idea why this occurs or how to fix it. Stack overflow to the rescue, hopefully get an answer.

I'm annoyed that I never ran the program in release mode for almost 3 weeks now, always been running it in the debugger so no idea what I did to break it.

SO thread if anyone has any ideas
http://stackoverflow.com/questions/4006 ... r-attached

Not to be a major pain.... but rip everything out of the j2534 dll and pop it into its own class in the main GUI app. Try step through the code like that and also run without debugger.. and see if it fails.

I know its more work.. but may help narrow down the dll issue.

I had an issue with a CRC calculator dll, application would instantly crash even with try/catch's. Had to copy the source into the project to find the problem instead of using the compiled dll.

The J2534 dll is c++and closed source. I could ask tactrix for it but probably easier for me to solve it myself.

rolls wrote:The J2534 dll is c++and closed source. I could ask tactrix for it but probably easier for me to solve it myself.

Ah, didnt realise it was closed. Never mind!

http://stackoverflow.com/questions/4007 ... ionpointer

Ok I've narrowed the problem down and found a workaround however it means hardcoding the DLL reference to use the OpenPort only. For some reason the UnmanagedFunctionPointer causes a stack overflow if a debugger is not attached, a stack overflow then breaks the exception handling in my program causing my exception to be unhandled despite being nested in a try catch block. If I use a plain old DllImport it does not occur.

Hopefully one of the greybeards from StackOverflow can help answer the question. Even if I can find a workaround I don't like not understanding why something doesn't work so I'll probably be fixated on this until I can fix it.

Mother fucker it appears to be an incompatibility with the OpenPort DLL and .NET 4.0, bug disappears if I roll back to 3.5. What a huge waste of time that was to figure out!