Blank / Dead Infotainment Screen

[marky mk 7]

Hey all,

I'm hoping to see if anyone has any advice for a blank infotainment screen. About a week ago the screen completely died on my USDM 2016 GTI Autobahn. It's totally unresponsive - no music plays, the backlighting doesn't work, touchscreen doesn't do anything, none of the physical buttons on the sides work, and the reverse camera doesn't display (though I do hear the camera moving like normal). It won't pair to my phone with Bluetooth or through the aux port.

It didn't really have any symptoms before it gave out, other than the volume randomly jumping up while listening to music that day. The screen died right after driving, parking for a few minutes, then starting the car back up again. It looked like it was trying to pair to my phone's Bluetooth when the screen shut off, and it hasn't worked at all since then. No unusually cold or hot temperatures outside.

I've been reading up on this problem and have already tried these suggestions:

• Holding the power button on the display and the eject button on the head unit for a minute each.
• Checking fuses for F10 and F12 and swapping them with known-good fuses.
• Disconnecting the battery for a couple hours.
• Pulling both the screen and MIB II control unit in the glovebox to check for loose connections.
• Removing and re-inserting the Nav SD card.
• Checking for codes with a basic OBDII scanner, which found nothing (I don't have access to OBD Eleven or VCDS, but maybe those would work better).

From other threads it sounds like the screen isn't likely to be the problem. Is there any reason to try replacing it with one from ebay, or is the unit in the glovebox much more likely the culprit? Is there a way to test for sure which part is defective?

If I replace the glovebox unit with a used one, will I run into component protection issues if it has the same part number? I'm debating going to the local dealer for this but it'd be nice to at least buy a used replacement part to save money if it won't cause more problems. I can call the dealer first and see if they'll remove the component protection before buying a used one.

Thank you to everyone who gives this a read and has any suggestions!

 

[DV52]

Mark: Hi.

My hunch (guess really) based on the list of tests that you have tried is that it's likeky the MIB that has gone pear-shape.

However, I'm surprised that you found no errors with the OBD reader. For a problem like this where the infotainment system is so unresponsive, I would expect at least a few error-codes to be generated and registered in fault memory! But then, you don't say which OBD reader you used, so this might be the reason for the test result.

Before you start buying new equipment, it would be prudent to check for error codes with a good diagnostic device - spending your hard earned dollars based on guesses ain't a good way to find faults!!

As for your other questions - alas YES, if ANY other MIB unit (regardless of part number) is replaced in this car, a Component Protection (CP) error will be generated. The CP test process happens after each ignition switch-ON, so this is when the error will appear if the identity of the new MIB isn't the same as that of the "authorized" MIB identity in the Gateway module

That said, there are MIB modules available that have been hacked to avoid the effects of CP - so this might be an alternative

And also YES, talking to your local dealer is a very good idea!! Understand your options before you throw money at a solution!!

Don

 

[marky mk 7]

Mark: Hi.

My hunch (guess really) based on the list of tests that you have tried is that it's likeky the MIB that has gone pear-shape.

However, I'm surprised that you found no errors with the OBD reader. For a problem like this where the infotainment system is so unresponsive, I would expect at least a few error-codes to be generated and registered in fault memory! But then, you don't say which OBD reader you used, so this might be the reason for the test result.

Before you start buying new equipment, it would be prudent to check for error codes with a good diagnostic device - spending your hard earned dollars based on guesses ain't a good way to find faults!!

As for your other questions - alas YES, if ANY other MIB unit (regardless of part number) is replaced in this car, a Component Protection (CP) error will be generated. The CP test process happens after each ignition switch-ON, so this is when the error will appear if the identity of the new MIB isn't the same as that of the "authorized" MIB identity in the Gateway module

That said, there are MIB modules available that have been hacked to avoid the effects of CP - so this might be an alternative

And also YES, taking to your local dealer is a very good idea!! Understand your options before you throw money at a solution!!

Don

Thank you for the very detailed reply, Don!

The OBD tool I'm using is a fairly low spec Amazon model, but I'll try running it again. I can drive to a parts store and borrow their code scanner, too. I didn't realize that the infotainment hardware was so likely to generate fault codes when it fails. That's great information for me to help narrow it down.

It's also really good to know that there are hacked modules out there to avoid the CP issues. That could be a really simple solution if it does turn out to be the MIB unit.

I'll plan to call the dealer after the holiday and see what they say if I haven't made any headway with the OBD scanning.

Thanks for taking your time to help me with this! I'll report back here with my findings in case it helps anyone else.

 

[marky mk 7]

Quick update on this.

I borrowed an OBD scanner from a parts place and it didn't show any codes either. It does seem like it's the unit in the glovebox at fault though, so I might try that first.

After talking to a dealership, they hadn't heard of component protections or lockouts before. They would help to code it to my car if needed, but won't guarantee that a secondhand unit will work. A used MIB unit is so much cheaper that it might be worth it to try, at least.

 

[backcountry]

Just get the correct MIB unit and remove CP yourself. Read the threads on this forum.

 

[marky mk 7]

Just get the correct MIB unit and remove CP yourself. Read the threads on this forum.

I'm actually looking into the CP removal now. Thanks for the suggestion! Going with the dealer seemed like a simpler solution, but I'll try it myself if it looks manageable.

 

[marky mk 7]

Got an update, finally. I ended up buying a used 5F MIB unit for the glovebox and that fixed it! I opted for a replacement using the same part number, which is not a Delphi unit and therefore can't have the component lockout bypassed using the SD card trick.

(Here's info on that in case anyone else finds this post in a similar situation: https://golfmk7.com/forums/index.php?threads/diy-mib1-mib2-new-simplified-method.429122/)

That said, component protection came on at first and then went away the next time I started the car. It only came back once when I turned the car off and back on again within a short time, but then went off again the next time I drove it.

Has anyone seen that before? It's almost like it's bypassing the component lock most of the time, but still gets tripped occasionally. I planned to have it reprogrammed at a dealer but it's fairly okay as it is now. From other reading, it looks like the ECU checks for component IDs during startup, then locks things that don't reply with the correct ID. It seems like it's automatically bypassing this check most of the time.

I'm not doing anything different the times it has component lock vs when it doesn't, that I'm aware of. It'd be interesting to know why the component protection is intermittent.

Thanks everyone!

 

[DV52]

@marky mk 7: I'm not sure why the CP error is intermittent on this car - I assume that you purchased a non-hacked 2nd-hand MIB from a donor car.

Your general understanding of the CP process is correct - but the detail is not (no offense intended)! This is how the CP procedure operates:

VW says that CP is intended as a solution to the trade in stolen parts on the black market. I will leave it to your judgement to decide if this is correct, or if the result of further entrenching dealer services into the life-cycle of the car was the principal motivation!!

Only key modules (like the MIB) are included in the "CP constellation" on MQB platform cars.

The "CP constellation" consists of two distinct parts: a master CP module, which is the Gateway module (not the ECU) - and a number of CP slave modules.

When the car was built, the identities of ALL CP modules were encryped into a CP master table which the Gateway module uses each time the CP process is initated. In essance, the CP master table defines the identities of the modules that have been authorized by VW for the car's VIN (so the contents of the CP master table is unique for each individual car)!

As I said in my previous reply - every time the ignition key is moved to the first position, the Gateway module initiates the CP checking process. The Gateway module request the identity of each module in the "CP constellation" and then it checks responses against the encryted identities in the CP master table. This process has the effect of also checking the identity of the master CP module (yes, changing the Gateway module will also generate a CP error because it is part of the "CP constellation")

If none of the key modules have been changed since a successful CP test on the previous ignition-ON cycle, the polling process results in no CP errors. If there has been a change in module identity, a CP error is generated both in the new module(s) and in the master CP module.

In theory at least, it shouldn't matter how many times the ignition is cycled because with each ignition-ON event, the same CP test process should be initated and it should yield the same result!

Plus, the situation in your particular car shouldn't matter -the installation of ANY new MIB in any MQB platform car should generate a CP error after the first ignition-ON event and this error should remain active until the formal VW error clearing process is undertaken (again, if the new unit has not been hacked). Clearly the original VIN of the donor vehicle for the new MIB is different to the VIN of this car -so a permanent CP error is expected!

To add to my description of the CP process above - this is how the formal VW clearing process works for CP errors:

A full copy of the complete software and module identities for every MQB platform vehicle that rolls-off the factory production line is kept on VW's central servers. This database is called FAZIT - the German acroym translated to english means Vehicle information and central identification tool.

To clear CP errors using the offical process, the car must be connected to FAZIT via a dealer link, or via an authorized independent-workshop facility using a registered GEKO account. The guided function process for clearing CP errors has a number of distinct parts which starts by checking if the new module has been reported as stolen. Assuming this is NOT the case and that the VW mother-ship approves the requested change, the CP error process then realigns the identity of the new module to the VIN of the recipient car. This modifies the encrypted CP master table in the car and CP identity of the new module - and it also modifies the information in the FAZIT database should future changes be needed

A second part of the CP error clearing process which is sometimes missed is the re-establishment of FECs from the old MIB to the new MIB. FECs are software licenses that authorize the various options the the buyer chooses at the time of factory build. Examples of FECs are SATNAV, Driver profile and Adaptive cruise control etc. These are SWAP (Software As Product) facilites that must be purchased from a dealer and the FEC licenses are stored in the MIB, or in the Gateway module.

When a new MIB is installed, it's important for the MIB specific FECs that were originally built into the car (and stored in the old MIB) to be in the new module - else the original factory installed SWAP facilities won't function!

Don

 

[marky mk 7]

@DV52

Thank you very much for the detailed reply! I have to say, I've come across some of your other posts while researching this, and they're all very thorough and insightful.

Based on how the CP system works, it does seem rather odd that mine has intermittent CP errors. To add more detail, I got the MIB from a donor car, and the seller listed that car's VIN for reference. I looked it up and found it to be the same year, and also an Autobahn trim. I figured it would have all of the same FECs since it looked like the factory options were similar as well. Nowhere was it mentioned that it was a hacked unit, though it is a possibility.

After it booted up the first time, it showed a line of text reading something like, "component protection is active", and still displayed most of the normal screen functions behind the text. When I turned it back on later, the message was gone and I had full access to all the various menus, SATNAV, Bluetooth, etc. The only thing missing is the performance monitor. I've been able to play music and use all of its functions like normal. Only once has the component protection line come back, and I haven't seen it since, even when trying to replicate the situation that caused it in the first place (turning the car off an on again within a short amount of time).

Does this sound more like a hacked unit to you, or potentially a fault in the CP module constellation that's allowing it to pass the check?

 

[DV52]

@marky mk 7: I have encountered very few instances of intermittent CP errors - they are as rare as rocking-horse sh#t!

When it has happened in past cases, the cause of the odd behavior has invariably been an ancillary part of the CP polling process, rather than the CP function, itself.

To explain, if my memory is correct - the last example of intermittent CP errors that I encountered involved a car that reported a SCAN with an implausible Terminal 15V status on the Gateway module.

Not sure if you are aware of T15 volts - it's the battery rail voltage in a car that is switched-ON ONLY when when the ignition key is moved to either the first, or second position. If the key-lock is in the OFF position, T15V=zero.

As I said in my previous reply, the master CP module (Gateway module) initiates the CP process after each ignition-ON event. One of the ways that the Gateway module knows when the ignition is switched-ON is via a T15V wire that is terminated on the module connector. The same T15V signal is also connected to almost every other module. Another "tell" for an ignition-ON event is a CAN based module wake-up message that is repeated continuously on the CAN network

Although not mentioned in my previous replies - the underlying assumption in the CP process is that ALL modules in the "constellation" receive a T15 signal at roughly the same time. This requirement seems to apply regardless of the timing of the CAN wake-up message

I suspect that coincident T15V signals on ALL "constellation" modules ensure that when the master CP module initiates the CP process, the slave CP modules are prepared to respond to their identity request. I'm not sure why, but it appears that a delayed (or missing?) T15V signal to any "constellation" module can generate intermittent CP errors!

I guess that quickly cycling the ignition key ON/OFF can also generate the same effect - but I have no idea if this relevant in your case

Don

 

[marky mk 7]

@DV52 Thank you again for your insight! I read it back when you posted but continued to work on fixing the issue in the meantime. I think what you're describing is exactly what was happening. It seemed as though cold starting the car immediately when getting in when allow the display to work, but doing something like opening and closing the hatch first would cause CP to kick in. You would know the system better than I, but my guess is that opening the back might cause some electrical systems to prep for the car to start, and maybe this allows the T15V signal to be read properly in the constellation. Perhaps when it's a cold start there's just enough of a delay to bypass the node responsible for CP checking on the display. Is something like that possible?

To close out the main topic of this thread (for anyone reading this for help), I did solve the issue!

The 5F Infotainment module in the glovebox was the culprit. A used OEM replacement with a matching part number caused the display to come back on, but it had some issues with component protection lockout. A quick trip to a local dealer had it sorted out with about an hour worth of work. They knew exactly what the issue was and got it sorted with no more component lockout issues.

A few tips I picked up along the way:

Both the display and infotainment module will require a set of specific removal tools. They can be had from Amazon for like $5.

Usually if the whole system goes unresponsive, it's the glovebox unit at fault. I couldn't find many ways to test for certain if it was the display or glovebox, so it might be best to choose whichever seems more likely, then get a replacement that can be returned in case it doesn't fix it.

The screen is a bit harder to access but is much cheaper to find used, and doesn't require removing any component protection. However, it looks like it's less likely to be at fault with these specific symptoms.

When buying a used 5F unit, it may not have all of the menu options (FECs) that the original unit had, even if it's from the same year and trim. It could be good to mention what's missing if the car is taken to a dealer to have the CP lockout fixed. They can add them back using your car's VIN to see what it should have unlocked.

Hope this is helpful!

 

[teereqs]

Just stumbled across your thread. I have a 2015 Sportwagen TDI, with the MIB1 unit, and the screen is flickering. I bought a used dash unit from a guy on one of the mk7 fb groups who did the MIB2 upgrade. I've been reluctant to install due to the CP. The closest dealer to me is about an hour away. Do you remember what they charged you to sort out the CP? I'm guessing around $200-300 if it was an hour worth of labor. I've also heard some dealers won't touch it if a used replacement was used.

Seems like all the threads about removing CP are for MIB2 units, but nothing about MIB1

 

[backcountry]

Just stumbled across your thread. I have a 2015 Sportwagen TDI, with the MIB1 unit, and the screen is flickering. I bought a used dash unit from a guy on one of the mk7 fb groups who did the MIB2 upgrade. I've been reluctant to install due to the CP. The closest dealer to me is about an hour away. Do you remember what they charged you to sort out the CP? I'm guessing around $200-300 if it was an hour worth of labor. I've also heard some dealers won't touch it if a used replacement was used.

Seems like all the threads about removing CP are for MIB2 units, but nothing about MIB1

If the MIB1 is in the glove box, there won't be any CP on the display.

 

[teereqs]

I swapped out the MIB1 unit for a good used one over the weekend. Fixed my flickering screen issue, but now I have the banner accross the screen reading: "Component Protection is Active". Going to call the dealer and see if they can reprogram it.

 

[teereqs]

Update on my issue. At the dealership right now, actually. They reprogrammed it to get rid of the component protection banner, but now I don't have any audio. I didn't have audio when I installed the new one, but thought that was because it needed to be re-programmed. The unit I replaced the old one with was from a car that had the Fender audio package. I noticed the Fender logo when I first installed it. Is a fender radio unit not compatible with a car that wasn't equipped with it in the first place? They were both Panasonic units and had the same exact part number