5 minutes ago, pupu14 said:

There is some weird/missing data in GDS2 log too..
Communication issues are totally not out of the question here!

 

OP, is your MDI2 original?

Try updating MDI software and firmware if necessary (write "bosch mdi software" in any search engine, it will take you to the right place). Also, do not use wireless connection.

Or your GDS2 and deliverable packet is quite outdated (from 2020..) and have some issues reading/interpreting data from newer control units.

 

I saw it was a VXDiag..  it really looks like it's having communication issues for sure looking at those logs.  I was wondering if the OP was running it wirelessly too.....  I run my VXDiag Nano wirelessly and it's pretty good but ....  if the OP is, it would be worth trying wired.  The log I reviewed, it clearly sent the first calibration (OS approx 65k) but retried like crazy to get there.  So I'm almost leaning really towards that being the issue now.

First of all. I am so taken for all these helpfull hands THANKS guys.
Then some input:
- cable is vcx nano, with GDS options. Finrware is latest(1.9.4.2) working fine with USB cable to other modules(SPS)
- DPS Log what you had been looking in first place is from reporgramming where used 33.1k and pin1. Maybe this explain those time outs ?

 

1 minute ago, mikko virta said:

First of all. I am so taken for all these helpfull hands THANKS guys.
Then some input:
- cable is vcx nano, with GDS options. Finrware is latest(1.9.4.2) working fine with USB cable to other modules(SPS)
- DPS Log what you had been looking in first place is from reporgramming where used 33.1k and pin1. Maybe this explain those time outs ?

 

I use the exact same unit as you, I have one that is wifi/cabled and one that is cabled.  

 

Do me a favour if you can?  Run DPS, try to program it then grab the file in C:\Programdata\vcx\logs\passthru\vcxpt32.log

 

Even better, if you can run the process through SPS then grab that file and share it here, that'll help more.  Just curious to see what that shows.  It shows MUCH more detail than DPS.

 

Here are few logs. Tested few minutes ago.

serial_b_VCXPT32.log serial_b_fail_pin1_83kb.Txt

7 minutes ago, mikko virta said:

Here are few logs. Tested few minutes ago.

serial_b_VCXPT32.log 56.72 kB · 0 downloads serial_b_fail_pin1_83kb.Txt 4.18 kB · 0 downloads

Perfect!  I know SPS didn't work but I see you're set to 83.3kbps, did you try 33.3kbps?  Most stuff I program at the lower rate but I will admit, I haven't done the newer SDGM.  I have one sitting here though that I can test if you get me our DPS A package too.

 

You didn't even get passed the security this time....  try 33.3kbps and let's see how far it goes.

25 minutes ago, mikko virta said:

Here are few logs. Tested few minutes ago.

serial_b_VCXPT32.log 56.72 kB · 1 download serial_b_fail_pin1_83kb.Txt 4.18 kB · 1 download

In fact, something in your settings even attempted to flip your VXDiag into J1850VPW (but it doesn't support it anyways):

 

[08:16:52.884] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[08:16:52.884] PassThruIoctl.
[08:16:52.884] ulChannelID = 1
[08:16:52.884] enumIoctlID = 0x00008000
[08:16:52.884] pChannel = 0x70db4080
[08:16:52.884] Unknow IOCTL ID
[08:16:52.884] [0x0000000f] J2534_ERR_INVALID_IOCTL_ID
[08:16:52.884] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 

#define J1850VPW_PS                        0x00008000

 

Again, if you can, flip it to GMLAN and set to 33.3kbps.  If it failed in SPS, I'm expecting it may again but I'd like to see the logs from that.  

Now tested by 33kb /pin 1

serialB_33KB_VCXPT32.log serial_b_fail_pin1_33kb.Txt

Just now, mikko virta said:

Now tested by 33kb /pin 1

serialB_33KB_VCXPT32.log 593.03 kB · 0 downloads serial_b_fail_pin1_33kb.Txt 15.23 kB · 0 downloads

 

 

Ok, so that again went through the first upload but encountered a lot of issues.  Definitely run this at 33.3kbps though because I've looked and I can see the security access request is for normal speed programming, not high so I'd expect that to fail.  However, you're still getting communication errors for some odd reason.  

 

Can you attach your DPS file? (the .zip)  I want to see something 🙂

I assume you look this ?

serialB.zip

3 minutes ago, mikko virta said:

I assume you look this ?

serialB.zip 35.13 kB · 0 downloads

That's it!

 

While I look at this....  I remember a TSB being released about removing the Onstar fuse, wait 30 seconds, put the fuse back in, turn the key on, then program.  Do you have Onstar?  Can you try that if so?

Yes, this car has onstar functionality(of course not working here in europe anymore)
So my steps should be:
1. open locked doors
2. onstar fuse(F31)  30 second "reset"
3. Put car service mode
4. Program by DPS using 33kb speed

8 minutes ago, mikko virta said:

Yes, this car has onstar functionality(of course not working here in europe anymore)
So my steps should be:
1. open locked doors
2. onstar fuse(F31)  30 second "reset"
3. Put car service mode
4. Program by DPS using 33kb speed

Close 🙂

 

1. Load DPS, select package, have it ready to program (GMLAN, 33.3kbps)

2. Ignition Off

3. Pull Onstar fuse, wait 30 seconds

4. Insert fuse (it doesn't specify turn key on or service mode - try with key off first - the SDGM may still be awake...)

5. Hit program immediately

Onstar reset tested with NO servicemode. Like before same result.
Maybe logs are showing is it exactly same

onstarreset_notservicemode_VCXPT32.log serial_b_fail_pin1_33kb_after_onstarreset_notServicemode.Txt

20 minutes ago, mikko virta said:

Onstar reset tested with NO servicemode. Like before same result.
Maybe logs are showing is it exactly same

onstarreset_notservicemode_VCXPT32.log 593.03 kB · 1 download serial_b_fail_pin1_33kb_after_onstarreset_notServicemode.Txt 15.23 kB · 1 download

I've got to sleep soon, just testing a few things.  Are you able to attach the Serial A DPS as well?  I'll set mine up on my bench tomorrow and see if I can program it.

of course i can put Serial A files.
 

 

serialA_VCXPT32.log serial_A_Servicemode.Txt

On 10/8/2023 at 1:33 PM, mikko virta said:

Hello,
I have a 2020 Opel Ampera-E, which is essentially a Chevy BOLT.
 I had a minor mishap with the SPS2 update, and the end result is that the K56B (serial gateway) update was interrupted. It was later revealed that this particular component should not be updated if there are HV DTC codes in the car (which I had).

 Now, the situation is that I can't connect to those modules with the GDS2 tool where those HV DTCs are located. This is because the Serial B gateway no longer functions.

So, I'm essentially in a loop where I can't update the Serial B Gateway because the fault codes have not been reset, and on the other hand, I can't reset the fault codes because the Serial B gateway is not working.

 

 I have saved (SPS cache) the BIN files that should be updated to the K56 module, but I wonder if they can be updated with DPS? 

 

And if I try to update them with that, is the situation the same as when updating with SPS?

 

Do I have any other options other than buying a K56 module??

 

Can I, for example, bypass the K56 with resistors and thus reset the HV DTCs???

I hope this helps! If you have further questions, please let me know. I am quite out

create archive by version 2 creator......

Interesting tip..
Just for curisioty, what is theory for version 2 is making any difference ?

 

2 hours ago, mikko virta said:

Here are few logs. Tested few minutes ago.

serial_b_VCXPT32.log 56.72 kB · 1 download serial_b_fail_pin1_83kb.Txt 4.18 kB · 1 download

if you have still issue on sps programming used module,, another way is to remove bcm pin code,, return pin after programming...

Interesting idea.
What kind of steps are needed for doing that kind of removing-returning ?

28 minutes ago, LLCasaol said:

create archive by version 2 creator......

There is no point of using creator or do packages manually. As well we try to flash module with official SPS, same timeout. They suggest is device issue as timing out. 

12 minutes ago, mikko virta said:

Interesting idea.
What kind of steps are needed for doing that kind of removing-returning ?

 

12 minutes ago, mikko virta said:

Interesting idea.
What kind of steps are needed for doing that kind of removing-returning ?

OPEN BCM,, READ EEPROM 95320 , PIN IS ON 00A0-789A GRAPH,, CHANGE 4DIGIT NUMBER TO FF

15 minutes ago, Lyubomir Krastanov said:

There is no point of using creator or do packages manually. As well we try to flash module with official SPS, same timeout. They suggest is device issue as timing out. 

LOT OF ARCHIEVE I MAKE HAVE ERROR ON VERSION1 THAT ALL DONE BY DPS CREATOR2,  AND IF TIMOUT OCCUR IN SPS,, MODULE HAVE ALREADY USED BY OTHER VIN,,,,,,,

 

2 minutes ago, LLCasaol said:

LOT OF ARCHIEVE I MAKE HAVE ERROR ON VERSION1 THAT ALL DONE BY DPS CREATOR2,  AND IF TIMOUT OCCUR IN SPS,, MODULE HAVE ALREADY USED BY OTHER VIN,,,,,,,

 

Packages is made manually according all rules. And yes - module glitch even in SPS programming. There is no issue of vin. Most likely is communication issue for me. 

3 minutes ago, Lyubomir Krastanov said:

Packages is made manually according all rules. And yes - module glitch even in SPS programming. There is no issue of vin. Most likely is communication issue for me. 

THE LAST ONE GMC SIERRA 2020 I PROGRAMMED SDGM WAS DONE AFTER I REMOVE BCM PIN .

 

I just heard from my friend that he got Openport2 cable(J2354) support.
I am now preparing to trying test re-porgramming by using that cable.
Any TIPS or pre warning ?