Help on vgs4 !

I had this with vgsnag3 w166. I have overwritten cff on smr. Then I barely got it back. But everything worked out.

Okaii some update, i have tried to flash in different ways with ecu unlock and so on but nothing helps still get the same error message, in both DTCM and VEDIAMO, as Gerboxexpert is pointing out the programming parameters in the tcm dont match the flashing parameters of DTCM and VEDIAMO somhow, i have found out that the SW i flashed Wrong is listed for BR217.

I have also tried to flash the same file i flashed wrong to se if i can unplugg at 1% but the flashing wont start, get fault message in Vediamo and the flashing just hang in DTCM.

I se that LAUNCH Ecu tcu programmer both standalone and G-box3 edition can clone VGS4 with there new update from January this year but has to be done in boot mode same way as Abrites, but cant find any info about erasing and flash new softwear to a damage unit. i might try this if i can get hold of a programmer.

---

I had this with vgsnag3 w166. I have overwritten cff on smr. Then I barely got it back. But everything worked out.

Can you explain more details ?

---

But there is somthing whit this error message i find intresting.

CAESAR: ProgBlock: 20441: FLASH - Condition Not Correct >ProgrammingMode< :  CAESAR: ProgBlock: 20441: FLASH - C

00002480 13:00:06 ondition Not Correct >ProgrammingMode<.

this progblock can that be change or somthing?

laissez les paramètres de communication tous standard pour l'instant,...déverrouillez l'ECU,...appliquez la programmation d'accès de sécurité DJ,..et essayez de le reflasher

INEED HELP

To establish a programming session (mode), the controller always checks if all preconditions are fullfilled. 

There are usually several of them, such as engine off, temperature limit, correctness of the memory structure or even permission from the immobilizer. They all are simply represented as flags in EEPROM, and these flags are set by the current software during initialization after ignition ON. So the software defines what will be the preconditions to reflash itself. Once they are set, you need to fullfill requirements on next boot to reset them again...

Here this is not about seed-key procedure or any external authorization, but the current state of the controller itself. Until this state (flags in EEPROM) changes, the TCM will always respond negatively to an attempt to establish a programming session. Theoretically, the negative response includes an code as argument for rejection. You just need to have a table to interpret the rejection codes.

I think the main reason here is the lack of confirmation from the driving authorisation system. In these controllers, as long as the activation is green, you can reprogram them even on the bench and with the wrong file.  

Try to force the activation to be "green" again somehow. It is only possible when TCM is in the car. Maybe setting another coding accepted by this wrong software can restore this data... The codings here (original was ap36) means not just configuration of parameters, but also data set integrity..  Try with: ap30 

Keep digging, we all will learn a lot from your mistakes 

Try to program a file with the SMR extension. I didn't unlock anything, but everything worked out. DTS projects for W205, W222

To establish a programming session (mode), the controller always checks if all preconditions are fullfilled. 

There are usually several of them, such as engine off, temperature limit, correctness of the memory structure or even permission from the immobilizer. They all are simply represented as flags in EEPROM, and these flags are set by the current software during initialization after ignition ON. So the software defines what will be the preconditions to reflash itself. Once they are set, you need to fullfill requirements on next boot to reset them again...

Here this is not about seed-key procedure or any external authorization, but the current state of the controller itself. Until this state (flags in EEPROM) changes, the TCM will always respond negatively to an attempt to establish a programming session. Theoretically, the negative response includes an code as argument for rejection. You just need to have a table to interpret the rejection codes.

I think the main reason here is the lack of confirmation from the driving authorisation system. In these controllers, as long as the activation is green, you can reprogram them even on the bench and with the wrong file.  

Try to force the activation to be "green" again somehow. It is only possible when TCM is in the car. Maybe setting another coding accepted by this wrong software can restore this data... The codings here (original was ap36) means not just configuration of parameters, but also data set integrity..  Try with: ap30 

Keep digging, we all will learn a lot from your mistakes 

Yes i i realy like the way of thinking here ! i have tried a variant of different codings already but maby if i can get a dump from an w217 with the eeprom i can try to write all the eeprom blocks from that car and maby the unit wil be happy. if anyone have a car with

HW 0009017100
SW 0009025831_001 Version 171100
From 2017-2019

And a dup of the tcm to share it will be great !

Maby i can work with that

Screenshot of the file that got flashed wong.

---

Try to program a file with the SMR extension. I didn't unlock anything, but everything worked out. DTS projects for W205, W222

[font="MHH Font", Calibri, sans-serif]i give it a try cant remember if i have tried it already :p[/font]