VAG-COM/VCDS EVERYTHING

**whatispro** · 29th December, 2018, 12:50 AM

Hello guys,

I'm a newbie on Vcds and i have 2 cables to repair :

1 old with 10.6.3 , atmega162, FTDI FT232RL

I have some questions about this cable:

I'm looking to upgrade it to the last version 18.9 but i have a doubt about the STC chip, i don't know if the PIN 9 is connected to something or not, what do you think about this ?

After, i have used the VAGCOM HWtype and found that it's HW0x46 but the Atmega chip seems connected with pin 34 and 35 to a no GAL chip ( is it normal ?) so is the bad HW programed on this cable or HW0x46 is the correct one ?

After for the second cable, vcds 18.9, atmega162, FT232RQ, not working properly.

So i would like to repair also, i have the same question than for the first cable.

The atmega chip (PIN 34 and 35) are connected to the GAL chip so from my point of view it was supposed to has a HW0x44 and it's not the case, the VAGCOM HWtype is showing me 0x46 so i don't know if i have to correct this injecting the 0x44 firmware / eeprom ? > could it be the reason why the CAN test is not ready ? ( my car has a CAN for sure , after 2011)

What is your opinion, please ?
I give you some pictures

Thanks in advance!

**Elektrik1** · 29th December, 2018, 01:06 AM

First cable - you need to solder Atmega pins and program with external programmer since bootloader is disabled, and you are good to go with kolimers solution. STC chip can be removed, also with removal of 10K resistor (you will find instructions in this thread).
Second cable can be repaired with kolimers pack directly (bootloader is Enabled). You can try both 0x44 and 0x46, read post 3455252. If CAN issue persists, check hardware.

**whatispro** · 29th December, 2018, 01:39 AM

Originally Posted by Elektrik1

First cable - you need to solder Atmega pins and program with external programmer since bootloader is disabled, and you are good to go with kolimers solution. STC chip can be removed, also with removal of 10K resistor (you will find instructions in this thread).
Second cable can be repaired with kolimers pack directly (bootloader is Enabled). You can try both 0x44 and 0x46, read post 3455252. If CAN issue persists, check hardware.

Hi Elektrik1, thanks for your reply,

Could you help me on the STC chip, how can i check if it's necessary to cut a pin of this chip or and the resistor ? , if you could show me on my picture, please ?

Thanks :-)

**Elektrik1** · 29th December, 2018, 02:08 AM

I am not sure where traces in your cable goes, I do own very similar cable, I have just desoldered STC chip altogether, why do we need it to be powered, increasing heat of 5V power regulator if we don't use this chip anymore.
20181229_030300.jpg

**Roma77** · 29th December, 2018, 10:36 AM

Originally Posted by Elektrik1

Uploading 0x46 JED file here for GAL16V8B(1_xxx), actually desoldered from working cable with RL chip using TL866 programmer. Read as both, SOIC and DIP packages, contents seems to be the same. Also read from another 0x46 cable with GAL16V8D(2_xxx) RL cable, contents are a bit different. This second dump did not have STC chip from factory, that's may be the difference.
0x44 from BL based GAL16V8B for reference.
Cheers!

Thank you friend, I ordered 866 plus from the Chinese, will come somewhere in late January and then connect to the experiments, you tried to upload the dump to pure ATF/GAL?, I am a little embarrassed by the fact that there are working dumps 0x44 but their size is 1KB, you have 3-4KB , and even Atmel recommends using the conditioning file (in the archive) two times before flashing the new chip.

**supermario333333** · 29th December, 2018, 02:08 PM

I want like recover my old 908 cable (FTDI232BM). Unfortunately it's not possible to set the VID/PID (0403/FA20) with the FT_Prog tool. As first I clear the EEPROM without issues. As next I apply my template and program the FTDI. After a port-cycle inside the FT_Prog tool the EEPROM looks good. If I re-scan the whole USB device (in the FT_Prog tool too) then a lot of values are wrong set in the EEPROM (e.g. VID 2403). I had think thats a issue from the cable but with an other cable the behavior is excat the same. The STC was desoldered and all PCB connections are fine. Maybe somebody can help me with further investigations. For that I would have a capture file from a Saleae Logic Analyzer. But for me looks the communication between FTDI232BM an the EEPROM l good too.

thx@all

**Elektrik1** · 29th December, 2018, 03:23 PM

Roma77, please compare those 4KB files with 1KB file, clearly TL866 programmer reads out 0x0 - 0x02176 regions, also saves files with CR only spacing (doubling empty lines), where 0x44 dumps found on internet contains only 0x256 -0x2176 regions with no spaces, that's the difference. I have just left files in original TL866 format in case someone wants to perform an upload with this programmer.

**Laique** · 29th December, 2018, 05:45 PM

Hi guys!
Glad that i found this topic

I'm looking for an upgrade to 18.2 or maybe 18.9. (This cable works now with 17.1.3.)

There are few things i dont know and hope you can help me.

Here is my cable that came to me last week.

49203262_2027062007591589_4630954775020568576_n.jpg

VAGCOM_HWTYPE tells me its:
FW Version: 1.96
HW Version: 0x46

Files that i've found in this thread seem to have the same FW version.

48422025_268291777173136_7539918566775062528_n.jpg

What should i do now?
Do i still have follow the FirmWare upgrade procedure or do i just have to install the newer VCDS, then crack it with VCDS_Loader, and then update the cable using VCDS?

thx

**liviudiaconu** · 29th December, 2018, 06:04 PM

That .jed files are full of "1'. You tried to read from GAL? GAL is read-protected, so, like in the case of protected Atmega, will read only garbage.

**C3H8** · 29th December, 2018, 06:18 PM

Originally Posted by Elektrik1

Uploading 0x46 JED file here for GAL16V8B(1_xxx), actually desoldered from working cable with RL chip using TL866 programmer. Read as both, SOIC and DIP packages, contents seems to be the same. Also read from another 0x46 cable with GAL16V8D(2_xxx) RL cable, contents are a bit different. This second dump did not have STC chip from factory, that's may be the difference.
0x44 from BL based GAL16V8B for reference.
Cheers!

Friends,
Jedec GAL files Elektrik1 uploaded here for 0x46 hardware are empty, the GALs you read back were all read protected. What a pity.
Ups,liviudiaconu was faster :-)

**Elektrik1** · 29th December, 2018, 06:23 PM

Damn, they are indeed different, 0x44 differs a lot...
sshot-2018-12-29-19-24-09-1.jpg

**Roma77** · 29th December, 2018, 06:37 PM

[QUOTE=Elektrik1;3459399]Damn, they are indeed different, 0x44 differs a lot...
sshot-2018-12-29-19-24-09-1.jpg[QUOTE]
Hmm, it did not work out well, henceforth either write what was not checked, or check for empty ones.

**hid3** · 29th December, 2018, 06:43 PM

Need to kindly ask some Chinese manufacturers to share the 0x46 dumps... That'd probably be the best approach

**liviudiaconu** · 29th December, 2018, 06:57 PM

And almost for sure, the manufacturer didn't share his content

...but..in my country we say "the hope dies last", so, we hope..

**Elektrik1** · 29th December, 2018, 07:14 PM

Well, then we can arrange brute-force of 0x46 GAL chip - generate truth-table for each input-output combination (using arduino or any other fast solution), and maybe then someone can write a code for GAL.

Or maybe C3H8 decompiled 0x44 logic can be rearranged for different 0x46 pins (if only pin-out is different).