Component Protection out of nowhere

[ibiglari]

Last night hen I got my car from the parking valet, the head unit was in Component Protection mode. I connected to it using my OBDEleven, and there were two fault codes; one in Dashboard saying power was disrupted a few hours earlier (when my car was sitting in the parking; I know because I checked dashcam footage which is permanently wired to the battery) and the other fault was in Infotainment unit saying Component Protection. I couldn't clear the Component Protection error, because it popped back again. I had to go to the Dashboard, open Tests, and toggle Component Protection Test, and then switch the car off and on. Then, head unit started working and ACC gave an error (ACC and Advanced Warning not available). So I turned the car off and on again, and everything was fine. Does anyone have any idea what's gone wrong?

[DV52]

Ibiglari: You do seem to have the most interesting problems - it's good to have you as a forum colleague!!

So, not sure if you are aware how/when component protection operates, but the master control module in the process is what VW calls J533 (data bus diagnostic interface) and what OBD11 calls the "Gateway" (at address hex19).

Every time that a terminal 15 switch-on sequence occurs (i.e. the ignition is turned-on), J533 takes a look at the identity of certain key control modules and it compares these identities with the data that it stored about these modules at the previous switch-on cycle. If the two identity lists don't line-up a component protection fault is initiated.

The suite of control modules that are checked by J533 form what VW calls a "constellation" and these modules include:

• [*=1]J234 Airbag control unit
  [*=1]J285 Control unit in dash panel insert (i.e. what OBD11 calls "Dashboard"
  [*=1]J428 Adaptive cruise control unit
  [*=1]J519 On-board power supply control unit (what OBD11 calls "Central Electrics"
  [*=1]J533 Data bus diagnosis interface
  [*=1]J685 Display unit for front information display and operating unit control unit
  [*=1]J794 Control unit 1 for information electronics
  [*=1]R Radio

If it is determined that a known constellation of devices is working in the same way as during the last driving cycle, then the control units are enabled for regular functions.

If this is not the case for a control unit, then the component protection is activated in this control unit, which has an impact on its function. For example, a classic symptom of CP for the infotainment unit (i.e. J794) is for the sound to be permanently muted (the unit otherwise works OK, but without sound). Another example is when the Dashboard module is locked by CP -all of the lights and the two clock dials permanement flash on/off and the center display keeps flashing the message "safe CP"!

When a component protection fault occurs in any of the constellation modules (usually) the ONLY way to remove the error is to visit your friendly VW dealer who hooks-up the car to VW's central database at head-office. (the system is called FAZIT). Supposedly, the database checks that the new control module hasn't been thieved and the entire palaver is meant to combat the black market for spare parts. Alternatively, some consider CP to be nothing more than yet another excuse to pay your local VW dealer for something that should be able to be managed outside the dealership. You can decide which is true!!

So with all this as background information, I'm intrigued why loss-of-volts caused CP errors ( without changing modules) and I'm even more amazed that you managed to delete a CP error though the sequence of steps that you describe (i.e. without the involvement of FAZIT) -The identity list for the constellation in J533 is kept in non-volatile memory - so loss of volts should not affect the database. And, even though no control modules in the "constellation" were actually changed, once the CP error occurs, it is meant to be permanent without a fix via FAZIT - extraordinary!!


Don

[kamold]

Pure speculation here.. If there were a low battery voltage situation you may have some modules able to power up whilst others need more juice to get started.
So the constellation may not be complete, causing the gateway to log a cp fault.
Then when the battery condition is restored, the full constellation powers up and matches the expected configuration.
Cp no longer being triggered.
Perhaps?

Sent from my HTC 10 using Tapatalk

[ibiglari]

@Don

Thanks for your detailed response. Your knowledge of how VW engineered their platform is amazing.

I'll get to my car within the hour, and will learn whether this has happened again or not.

@Kamold
You have a point. Although this morning the car started up with no issue at all.

I tried to find error codes in OBDEleven app's history but apparently only coding is saved

[ibiglari]

Another question, my car is still under warranty. When I return the car for service, do I have to undo whatever I have done in adaptation and coding? Anti hijack, staging, lap counter, refuel quantity, etc...?

[kamold]

No.
Unless it throws a fault code they won't know let alone care.
If you come in with busted coding all over the place which causes modules to actually complain they will just restore to the factory config

Sent from my HTC 10 using Tapatalk

[ibiglari]

Well, no module is complaining. But it's quite obvious as I have linked day lights to hand brake, enabled acoustic feedback on door lock, and enabled staging.

Anyway, as long as they don't care, I'm happy. I hope they update the firmware with correct encryption keys for SUNA 😯. I'm dying for traffic updates

[DV52]

Pure speculation here.. If there were a low battery voltage situation you may have some modules able to power up whilst others need more juice to get started.
So the constellation may not be complete, causing the gateway to log a cp fault.
Then when the battery condition is restored, the full constellation powers up and matches the expected configuration.
Cp no longer being triggered.
Perhaps?

Sent from my HTC 10 using Tapatalk

Kamold: hmm........... I'm very nervous not agreeing with anything said by someone of your experience and knowledge, but it still doesn't make sense - sorry! If the slower modules fail to respond when interrogated by J533, I would have thought that nature of the DTC would be very different!

I am willing to be corrected, but CP errors (I believe) only result when the CAN gateway module detects a module with a different identity - meaning that there has been an successful completion of the comparison process. It doesn't make sense to generate a CP error where there is missing data from the module (I think)

But at least you have a hypothesis - better than me (I can't even think of a suggestion that fits the data)!!

Don

[ibiglari]

Tonight, no CP. Every component behaved.

Here's another piece of information regarding that CP error. Last night, the battery was really depleted. I kept the car on Star Stop Status screen the whole way home, a good 50 km along M5, and it kept saying Power Consumption High for most of the way. I'm sure it was recharging the battery because fuel economy was quite poor (5.1 compared to 4.8 every other night). Maybe low voltage somehow disrupted communication between modules? I come from an electronic and software background, and I know how certain binary errors are prone to being detected by simplistic checksum algorithms used in communication protocols.

[kamold]

Kamold: hmm........... I'm very nervous not agreeing with anything said by someone of your experience and knowledge, but it still doesn't make sense - sorry! If the slower modules fail to respond when interrogated by J533, I would have thought that nature of the DTC would be very different!

I am willing to be corrected, but CP errors (I believe) only result when the CAN gateway module detects a module with a different identity - meaning that there has been an successful completion of the comparison process. It doesn't make sense to generate a CP error where there is missing data from the module (I think)

But at least you have a hypothesis - better than me (I can't even think of a suggestion that fits the data)!!

Don

My experience and knowledge of mqb and cp is a big fat zero so please disagree away
My speculation is based on an assumption that cp is an all or nothing affair.
Take a hashed value of all relevant serial numbers and xor with known value (I'm sure it's more complex than that)
If you get a non zero return then throw a cp fault in the gateway.
If one eeprom was insuffiently energized during the interrogation phase it could have resulted in a value of 00000000 when it expects 1234ABCD.
Then next time it powers up OK and our hashed value xor with known value is zero so happy days.

If you insert a module with no CP for example (and gateway expects CP) you will have a CP fault on the gateway to flag it, but everything still functions.

[Guest001]

Im no expert but does the dashcam have a low voltage cutout on it. Some cameras continue to record in parking mode therefore using power. All of mine have a Power Magic which cuts power at a certain battery level thus stopping a flat battery

[ibiglari]

My dashcam cuts off at 12. Thus I am sure it wasn't it's fault. And the battery wasn't flat. Just very depleted

[DV52]

My experience and knowledge of mqb and cp is a big fat zero so please disagree away
My speculation is based on an assumption that cp is an all or nothing affair.
Take a hashed value of all relevant serial numbers and xor with known value (I'm sure it's more complex than that)
If you get a non zero return then throw a cp fault in the gateway.
If one eeprom was insuffiently energized during the interrogation phase it could have resulted in a value of 00000000 when it expects 1234ABCD.
Then next time it powers up OK and our hashed value xor with known value is zero so happy days.

If you insert a module with no CP for example (and gateway expects CP) you will have a CP fault on the gateway to flag it, but everything still functions.

Kamold: OK- I acknowledge that your hypothesis may be correct, but it seems far fetched - again my apology. I guess that we will never know - unless the incident happens again (which I hope is not the case).

Anyhow, whilst I am not entirely comfortable with your theory, it does fit with ibiglari's explanation of how he/she? removed the error. Notwithstanding the process described in the first post of "Dashboard, open Tests, and toggle Component Protection Test, and then switch the car off and on", I suspect that the real fix was actually just the last part - "car off and on". This action initiated a terminal 15 re-test of the identity in the previous constellation with the details of the then current control modules. Result of the re-polling test was that the two lists matched - so no CP error.

Don

[ibiglari]

I agree with Don. Probably turning the car off and on again after a while with enough juice in the battery caused all components to be able to identify themselves properly.

[kamold]

Like most things these days that are more software than hardware - 'have you switched it off and on again' is the answer to most problems

@DV52 - Don as you said unless the problem is reproducible the root cause may never be known (I have to deal with that sort of thing in my work life) but its certainly an interesting little gremlin. Lets hope it stays that way and doesn't get fed after midnight...