Since customizing the use of my rear fogs via coding (using BimmerCode), I have had a code that wouldn't clear: 8041C3, Lamp mapping failed. Been trying to chase down root cause for 2 or 3 years, because the lamps do what I want them to anyway (making backtracing via symptoms harder -- the only symptom I had was the trouble code).

Finally, courtesy of a single sentence in a post over at Bimmerpost, I found root cause: I had dueling priorities in my custom use of the output device (the rear fog lamp). Or in my case, dueling priorities for my custom use of each rear fog lamp.

Well, the post said this:

To accomplish what I wanted, I have "borrowed" the following output channels (and their respective right-hand aka "R" peers):

1. MAPPING_NEBELSCHLUSSL_L_OUTPUT (on the F56, not normally used/normally set to 0x00 - off unless rear fog switch is installed, and I have no rear fog switch)
2. MAPPING_BRAKEFORCED_2_L_OUTPUT (on the F56, not normally used/normally set to 0x00 - off)
3. MAPPING_STANDL_H2_L_OUTPUT (on the F56, not normally used/normally set to 0x00 - off)
4. MAPPING_TAGFAHRL_1_H_L_OUTPUT (on the F56, not normally used/normally set to 0x00 - off)

And set all four to 0x1C (rear fog, left, for the "L" parameters) / 0x1D (rear fog, right, for the "R" parameters).

And then told each of them to act as output channels for the following four (4) logical functions:

1. MAPPING_NEBELSCHLUSSL_L_FUNCTION (and R side as well): normally set to rear fog light (0x0E aka nebelschlusslicht), changed to front fog light (0x08 aka nebelscheinwerfer)
2. MAPPING_BRAKEFORCED_2_L_FUNCTION (and R side as well): normally set to bfd (0x0D aka brake force display), changed to brake (0x0C aka bremslicht)
3. MAPPING_STANDL_H2_L_FUNCTION (and R side as well): normally set to running/standing light (0x01 aka standlicht), no change needed
4. MAPPING_TAGFAHRL_1_H_L_FUNCTION: normally set to DRL (0x04 aka tagfahrlicht), no change needed

Note that none of the function assignments immediately above have an "instead of" effect, they are "in addition to." For example: the regular fog light switch still turns on the regular [meaning front] fog lights, as that is controlled by other code -- but additionally, with the setup above, the front fog light switch will also activate the rear fog lamp bulbs.

In this setup, I never tinkered with the priorities (MAPPING_blahblah_PRIORITY) in place for these. Why? (1) there was no obvious need to (the lamps were doing what I wanted) and (2) I didn't understand the PRIORITY assignments anyway. So the priorities in place for them (and their "R" peers) were:

1. MAPPING_NEBELSCHLUSSL_L_PRIORITY (left at default: priority_0 aka 0x00, which is top priority)
2. MAPPING_BRAKEFORCED_2_L_PRIORITY (left at default: priority_1 aka 0x01)
3. MAPPING_STANDL_H2_L_PRIORITY (left at default: priority_3 aka 0x03)
4. MAPPING_TAGFAHRL_1_H_L_PRIORITY (left at default: priority_3 aka 0x03)

Items 3 and 4 above were both set to priority_3 aka 0x03. This was a conflict, and the cause of the 8041C3 "lamp mapping failed" trouble code. The purpose of the priorities is to determine which function "wins" if two are trying to control the OUTPUT device at the same time. Example: Fog activation is going to override use as brake lights in my setup, every time. When used as rear fogs the lamps are brighter (higher PWM setting) than when used as brake lights, and I have custom voltage/brightness differences set for the standing/running and DRL uses of my rear fogs as well. Four functions, four brightness levels. The PRIORITY value determines which usage takes precedence over the others in real time use.

In my case, items 3 and 4 would never happen at the same time. Standing/running lights are in play when the parking lights and headlamps are on -- when the parking lights and headlamps are on, DRLs are off. So they never bumped into each other in a way I could visually observe, to in turn tell me that this is where I had a conflict (which is what the 8041C3 was complaining about).

Had it not been for @mrpingu 's post over in Bimmerpost, I never would have flushed this out. So big thanks, @mrpingu .

My resolution: I changed MAPPING_TAGFAHRL_1_H_L_PRIORITY (and its "R" side peer) from priority_3 0x03 to priority_4 0x04. Codes cleared after that and... the 8041C3 is gone.

If you have an 8041C3 in a different context, these specific output devices/functions may not apply to you, but I would recommend you look over your light-coding customizations and see where you might have PRIORITY value conflicts like the above. Easy to run into, especially if "borrowing" otherwise-unused parameter sections.