bri3d / VW_Flash

Flashing tools for VW AG control units over UDS. Compression, encryption, RSA bypass, and checksums are supported for Simos18.1/6/10, DQ250-MQB, DQ381-MQB, and Haldex4Motion-Gen5-MQB.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

VW Jetta GLI, Simos 18.2

il2evo opened this issue · comments

Hello!

Thank you for your work!

I am having issues with OBD unlocking on Simos 18.2 (Jetta GLI, 2016).

While writing the OBD unlocking file into ECU the process randomly gets stuck on random stages. I've tried different Openport cables, different laptops (just in case). It didn't make any difference.

Attached is the log from VW_Flash GUI.

I also noticed the following error in the background:

dashing module not loaded Traceback (most recent call last): File "VW_Flash_GUI.py", line 478, in update_bin_listing AttributeError: 'FlashPanel' object has no attribute 'current_folder_path' 2022-09-16 17:25:51 [CRITICAL] VWFlash: Selected: C:\VW_Flash_GUI_0.2.11\VW_Flasg_GUI\Unlock\FL_8V0906259H__0001.frf

Please let me know if you have any ideas about the possible cause of the issue, and if there is any additional information I may gather.

Thanks in advance!

log.txt

Odd. I have a number of users on 18.2 without issues (it's the same as 18.1 at the end of the day - still SC8 project correlation code). Although, I think most of them are using the Switchleg / A0 ESP32 hardware instead of OpenPort.

Usually random failures like this are caused by the transmit STMin (transmit message timing) parameter being incorrect causing frames to drop on the CAN bus. Maybe it is too aggressive for the PQ CANbus on OpenPort.

If you're comfortable editing code, you can set an stmin_override here:

workshop_code=workshop_code.as_bytes(),

by just adding another line:

stmin_override=500000,

I have meant to add this to the GUI but haven't had the time, this is good inspiration for me to do so.

Thanks for the response!

I will try that, although I am struggling a bit with a source code version, specifically with building the compressor. But that has nothing to do with the software itself.

The only problem besides that is the source code version doesn't see J2534 drivers (release version does), so I am trying to figure that out.

If I can't, I will wait for the next release version then.

Anyway, thanks a lot for your advice! I'll post here if i am able to apply your solution and test it.

If you are running the source version in 64-bit Python, you need to switch to 32-bit.

Most J2534 drivers are 32-bit, and I bundle 32-bit Python with the release version to avoid this issue.

The cable manufacturer actually provides both 32 and 64 bit drivers. I've tried both with 32 and 64 bit Python,with the same result:
2022-09-21 02:44:26 [ERROR] VWFlash: No J2534 DLLs found in HKLM PassThruSupport. Continuing anyway.
Just in case, Python version is 3.9.13. Originally I tried 3.10, but wxpython 4.1.1 doesn't build with it.

I guess I will have to wait for the release version, because the same drivers were working fine with it previously.

So I've eventually figured out the problem with drivers and built the compressor. Everything seems to be working, but the GUI is just missing the "Flash" button. There is no dropdown with available actions and no button.

Screenshot is attached.
vw_flash

Do you have any ides about what else I might be doing wrong?

I don't feel comfortable doing the same from cli, so I would really prefer to use GUI, because I've used it successfully with another car (release version).

It doesn't, but I feel like this is something with this specific laptop, because I've downloaded pre-built version and that button doesn't appear there too. So I'll try to build the environment on the old one, where it was working.

I was previously posting from friends account, that's also me, sorry for spaming :)

Just a random thought, but I have seen windows display scaling affect this. Could try changing that to see if the buttons appear, and/or tweaking the GUI width/height.

You are right! It was scailing!

However, unfortunately, the issue still persists. It gets stuck. Please find the logs and the screenshot attached.

udsoncan.log
vw_flash_stuck
.
flash_details.log
flash.log

Did you managed back to fully stock FRF after unsuccessful unlocking?

I have same car with same hardware number ECU try to flash with J2534 (Openport 2.0 or Scanmatik 2)....

Did you tried another j2534 tool instead of Scanmatik?

image

Yes, we didn't brick it :D

It is running a stock now. And we don't have Scanmatik. Tried Openport and a different J2534 adapter.

btw, we actually have reports from other people using this software who had the same issue with the process getting stuck, but they've managed to finish it successfully after several attempts. The same didn't work for us, unfortunately. As far as I know, they were using the same adapter.

Hello

Yes, we didn't brick it :D

It is running a stock now. And we don't have Scanmatik. Tried Openport and a different J2534 adapter.

btw, we actually have reports from other people using this software who had the same issue with the process getting stuck, but they've managed to finish it successfully after several attempts. The same didn't work for us, unfortunately. As far as I know, they were using the same adapter.

Same part number as yours and Simos 18.2 worked like a charm with OP2.0 :) no stuck or something.

Where did you get the frf file for unlocking from? Mine is from vw flashdata database. I am thinking that maybe the issue is in the frf I am using. The name is correct according to docs, but maybe it is just broken... I've tried OP 2.0 already, but with the same result.

And also what is the name and size of yours? Just want to compare.

https://we.tl/t-plpf95UlUK

here unlock frf
your OP is genuine or china clone?

It is genuine, but that was not the problem. You probably just have the same ECU, but a different car. Looks like this is just a GLI issue.

For Brian:

Your advice worked! I've increased "stmin_override" to 700000 today. Unlocking was a bit slower, but it worked on the first attempt! It got stuck once at importing bin later but worked fine after restart (without increasing further).

So for the next release version, you may probably want to have an option for a bit higher value to make sure it works for other unfortunate GLI owners :) But in general, that was exactly the solution! We have flashed it successfully.

Thank you for the assistance and for this great tool!

The cable manufacturer actually provides both 32 and 64 bit drivers. I've tried both with 32 and 64 bit Python,with the same result: 2022-09-21 02:44:26 [ERROR] VWFlash: No J2534 DLLs found in HKLM PassThruSupport. Continuing anyway. Just in case, Python version is 3.9.13. Originally I tried 3.10, but wxpython 4.1.1 doesn't build with it.

I guess I will have to wait for the release version, because the same drivers were working fine with it previously.

I using Scanmatik 2 and have same problem , how did you manage to solve this problem?

Check the first reply from bri3d on this thread. That was the solution, but I've used

stmin_override=700000

Instead of 500000.

You'll have to use the source code version though, so you'll need to build the environment. But you can check /docs/cli.md file for details and commands you will need (you can still use GUI after that, this cli doc just has instructions for modules installation and compressor compiling).

In my case what I had to install is: 32 bit Python (3.9.* because wxpython 4.1.1 will not work with 3.10), modules from "requirements.txt', Microsoft Visual C++, make and gcc to build the compressor (I've used MinGW for both).

Or you can just wait for the next release :)

Or did you mean the problem with drivers not being seen? In this case, it was purely my mistake. I was downloading the wrong drivers.

Hi! I have added a few fixes to the latest release version v0.5.2:

  • The default STMIN_TX is now 350000 (will be rounded to 400000us / 0xF4 for J2534 devices), up from 250000 (rounded up to 0xF3 for J2534 devices). Flashing will be a tiny slower but should be somewhat more reliable across the board.
  • For cars with specifically bad transmit framing issues, like these PQ cars, there is now a slider in the Interfaces menu in the GUI - you can select the transmit separation and keep jacking it up until things work.
  • J2534 drivers which are incompletely installed in the Registry will now be skipped instead of crashing the program.

This should resolve all of the issues discussed in this thread.