46 minutes ago, mikko virta said:

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 ?

It should be fine as long as it's a pass-thru.  I've checked the package too and even recreated it for fun, it's not the package at all.  This is a timeout issue, Lyubomir has put the files in the correct order.  The log clearly shows the timeouts.  If you have another pass-thru device though, it's worth trying that.  I'll try the packages on mine here in a bit too.

 

1 minute ago, codebuilder said:

It should be fine as long as it's a pass-thru.  I've checked the package too and even recreated it for fun, it's not the package at all.  This is a timeout issue, Lyubomir has put the files in the correct order.  The log clearly shows the timeouts.  If you have another pass-thru device though, it's worth trying that.  I'll try the packages on mine here in a bit too.

 

I even request VCI from TIS to force load files and them response is, most likely device issue. As been try to flash via dps and separately via SPS. Both ways…same issue. Timeout. Probably VXnano cannot handle packages encryption or protocols switch timing.

Damn, Openport 2 is only having Hi CAN. Lo Can is missing, and that's needed for Serial B (pin1 )

Have to find other brand cable.

BTW What we should ask from VCX nano for next Firmware ?  Maybe it is really small fix them ....

1 minute ago, mikko virta said:

Damn, Openport 2 is only having Hi CAN. Lo Can is missing, and that's needed for Serial B (pin1 )

Have to find other brand cable.

BTW What we should ask from VCX nano for next Firmware ?  Maybe it is really small fix them ....

I'm just testing mine right now on the bench.  I'll see what mine does :).

 

4 minutes ago, mikko virta said:

Damn, Openport 2 is only having Hi CAN. Lo Can is missing, and that's needed for Serial B (pin1 )

Have to find other brand cable.

BTW What we should ask from VCX nano for next Firmware ?  Maybe it is really small fix them ....

I'm having the EXACT same problem!  Let me try a few things here.  This is on the bench with nothing else on the low speed bus.  I'm going to try a few things and let you know.

 

At least it is great to see that it is not related to my cable or car.
Too Shame for VCX nano if they procols basically failing updates via Can Lo. I was victim for low quality Protocol 🙂

17 minutes ago, mikko virta said:

At least it is great to see that it is not related to my cable or car.
Too Shame for VCX nano if they procols basically failing updates via Can Lo. I was victim for low quality Protocol 🙂

I think it's the VCX Nano having issues.  I don't have a true MDI to test with unfortunately.  I've even tried to flash the same calibrations that my SDGM came with and I still have the same problem.  I'll try a few things.  The VCX Nano hasn't let me down before so I'm a little surprised.  I've programmed radio's, IPC's, all on LSCAN with no issues at all.  So this is strange for sure!  And this is on the bench with nothing else on the low speed bus right now (I purposely unplugged everything and this is the only device I see in the ECU matrix).  It must be the VCX.  I've tried both my non-Wifi and my Wifi one, same results.

 

I'm going to try and add some delays to the Utility to see if I can get it to go.  

Do we have enough detail for making BUG for VCX nano ?
 

24 minutes ago, mikko virta said:

Do we have enough detail for making BUG for VCX nano ?
 

I think we need to see someone do it with another device first...  It's interesting because it loads most of the OS then fails.  Again too, I've tried the matching one for my unit and it wouldn't load properly.  I even edited the utility and made it skip the OS but of course, it didn't like that (as I expected). 

 

Even though mine claimed to make it through the OS upload, it didn't save it.  This is what I got:

 

   * PEC Status:    0x0002   Err_SwNotPresent;  This error indicates an attempt to program a calibration module while the ECU is not fully programmed with valid application software.
 

I don't think our VCX's are transmitting properly.  I'm going to put a sniffer on and see if it's transmitting properly.  I'm wondering if it's related to ISO15765 and the VX.  I should be able to see it on my trace.

 

What cables we know that has J2354 and CAN LO ?
- autel j2534
- scanmatik 2
-  mdi

keep coming more cables so i can start asking how might have........

19 minutes ago, mikko virta said:

What cables we know that has J2354 and CAN LO ?
- autel j2534
- scanmatik 2
-  mdi

keep coming more cables so i can start asking how might have........

I'll have to look.  My trace shows everything's normal...  I'm wondering if it has to do with this:

 

[11:20:47.405] ulNumOfParams = 1
[11:20:47.405] Config #0     STMIN_TX
[11:20:47.405] Parameter:    0x00000023
[11:20:47.405] ulValue:    0x00000000(0)
[11:20:47.405] [0x00000000] J2534_STATUS_OK
 

STMIN_TX: get the ISO-TP transmit separation time (logical channels).  <-- It makes calls to this quite frequently

 

I have never seen this with radio programming or IPC before.....  I don't think the VCX Nano is returning the proper number (I could be wrong).  I might add that into my program and see what value it gives me back.

 

My sniffing trace, everything looks normal.  There's no missing packets, etc...  

It is amazing to see how deep someone can be on protocols and CAN messages 🙂

9 minutes ago, mikko virta said:

It is amazing to see how deep someone can be on protocols and CAN messages 🙂

I got crazy into this stuff :).

 

I've found some Ford forums where it looks like they're having issues with STMIN as well with the VCX devices but not with others.  The firmware log shows that it looks like they've added it back in 2015.  I'm thinking it's not working properly which lines up with the "timeouts" when the SDGM is actually responding.  I think we need to try another device unfortunately.  I've been tempted to get a different MDI :).

 

I'll paste below to kind of give you an idea.  One is a sniff (two devices on the line) and the other is DPS attempting.  All of the packets are there, it's like DPS isn't waiting long enough because the VCX is giving back the wrong value.  At least, that's why I'm believing now.  Especially as I've never seen DPS make that call before with other programming.  I'm convinced now it's the VCX.  I'm going to email them about that parameter and see what they say.

 

And if they are not responcing anyway i will go the shop web page and give my FEED BACK 🙂
 

they not likely to respond, may be will say you need to get new VCX SE device as your car is newer...

Just now, Lyubomir Krastanov said:

they not likely to respond, may be will say you need to get new VCX SE device as your car is newer...

I feel you're right haha.  In one aspect, at least it works for 99% of what I do 🙂

that I have vxnano and mdi clone. Soon plan to get scanmatic or autel j2534 device to cover newer protocols and requirements. Or slam and buy OV VCI is about 900EUR

I think the problem is that the files
new sample compressed and signed
and the block processor decompresses them on the fly
and only then writes to flash
at the end it checks the signature hashes
it takes time
I will give Lyubomir the already decompressed OS file
try it

 

2 years ago, I flashed a used module k56 from a 2019 Bolt on a 2019 Volt. Everything went successfully.  my adapter clone GM MDI  

5 hours ago, Stolik05 said:

2 years ago, I flashed a used module k56 from a 2019 Bolt on a 2019 Volt. Everything went successfully.  my adapter clone GM MDI  

Yeah, unfortunately this one isn't quite that.  But I am curious to try one of those clones.

8 hours ago, KZV said:

I think the problem is that the files
new sample compressed and signed
and the block processor decompresses them on the fly
and only then writes to flash
at the end it checks the signature hashes
it takes time
I will give Lyubomir the already decompressed OS file
try it

 

I tested and behauvior is littlebit different. Obvioisly upload time gets longer but still ending to error. 

NOtCompressed621_ProgramLog.Txt not_compressed621_VCXPT32.log

1 hour ago, mikko virta said:

I tested and behauvior is littlebit different. Obvioisly upload time gets longer but still ending to error. 

NOtCompressed621_ProgramLog.Txt 30.59 kB · 0 downloads not_compressed621_VCXPT32.log 1.49 MB · 0 downloads

It doesn't make sense.  Did you try another device or are you continually trying with the VCX?  I can probably write an app to handle it better but I'm leaning that since with even my module, I can't program the original modules that were in it, it's the VCX.  If I have more time haha, I could write a program that handles it differently.  As I've mentioned, I've never seen any other low speed programming make that call.  I think we've actually hit a bug in the VCX Nano.

Sorru for not mention that test was done by using same VCX nano adapter.
I am working on to trying get other brand adapter on my hands.  It is not easy task, ecspecially at weekend 🙂

Not ampera but is it possible to require ignition off/service mode off. There is nothing mentioned in TIS

That is really interesting. As simple say, do not use charger (use BSU), ignition off (and hint how to keep door open or any other compartment). Then waiting time is 5 minutes 🙂