Hi all, I'm new here. Most of my previous troubleshooting experiences have led to internet searches landing me at honda-tech forums. And now I have a problem to which I'm not finding answers anywhere else, so I'm posting here in the hopes that someone here understands the wiring and programming of these modern Honda's well enough to school me and allow me to fix my issue.

Background: I recently swapped out the CVT on my 2018 civic hatchback sport touring (Canadian) for a MT. Mechanically the swap is successful, and I've been able to enjoy driving the car. Apart from the mechanical components (transmission, axles, mounts, etc.), I swapped the PCM and the VSA/ABS module. I removed the TCM along with the CVT itself. The wiring for the clutch pedal to the PCM, to the BCM/MICU, and to the VSA/ABS module are all connected. I did not swap the BCM/MICU (yet), the gauge cluster (gauge control module), nor the multipurpose camera unit. The Canadian 2018 HB sport touring MT civic included the suite of active safety features (CMBS, LKAS, etc.), as did the CVT version.

Problem: There are three remaining DTCs I cannot clear.
1) GAUGE permanent DTC - U0101 - gauge control module lost communication with AT
2) Integrated Driver Support System Permanent DTC - U0101-F1 - lost communication with the PCM/TCM (Multipurpose Camera Unit)
3) Integrated Driver Support System Permanent DTC - U0101-00 - lost communication with the PCM/TCM
Having the DTCs, I can live with. They make sense, since the CVT has been removed. But more importantly, the dash persistently shows there to be a problem with the CMBS, LKAS, Adaptive Cruise Control, and Auto high-beam. As well, where there used to be the gear indicator on the dash (P, R, N, D, S) there is a flashing symbol to indicate an error. I would like to get these Honda sensing features working (except adaptive cruise control, which I don't think is equipped on the MT cars) and if possible eliminate the flashing gear symbol, essentially clear the dash.

Ideas: So far, I believe I've localized the issue to the F-CAN circuits. My understanding of these CAN setups is extremely basic, and perhaps incorrect. I'm hoping someone will be able to help me understand better. From what I've read online, I understand that on these F-CAN circuits, information can be sent to and from in the form of packets of data. And each packet will include some sort of identifier and some value data. All these modules (MICU, PCM, VSA/ABS, multipurpose camera unit, TCM) are connected on this F-CAN line, sending and receiving information between each module. So my guess is that the gauge control module "knows" there is no information coming from the TCM, as it has been disconnected from the F-CAN circuit and there are no data packets coming to it with an identifier associated with the TCM. It thus throws a code (the first U0101 listed). Likewise, the Multipurpose Camera Unit is "expecting" information along the F-CAN line with the TCM's signature and is not getting it, thus throwing a code (U0101-F1). As for the U0101-00 code, I wonder if this is the BCM/MICU expecting TCM-identified data from the F-CAN and not receiving it. Not sure. This is just my guess and crude description. Does anyone know if this approximates what is actually happening? I'm guessing each module is specifically programmed to expect data from every other module intended for that model/trim. So when a component is missing, the other modules "complain."

One potential solution, based on that understanding, would be to swap the BCM/MICU, swap the Gauge control module (dash cluster), and swap the multipurpose camera unit. Is that correct? For me, that is an impractical solution, regardless. I do have a BCM/MICU on hand, but swapping it in will require both some adjustments in wiring and having the dealer do the new BCM/MICU immobilizer registration. The dealer won't change the wiring for me, so I'd have to do it myself. And I'd then need to swap out the BCM/MICU to align with the wiring, but the car would be unable to start/undrivable and need to be towed to the dealer. As well, I'm not prepared to swap out the gauge cluster. My understanding, again maybe wrong, is that an odometer reading can only be written to a new gauge cluster unit, cannot be written over an existing odometer reading, and can generally only be done by the dealer. I don't want to pay the price of a new gauge cluster, and even if I did want to pay, the Canadian version of this trim is pretty well impossible to buy new now. The multipurpose camera I suppose could be swapped, but I had not planned on sourcing one.

So the other idea I had was to simply reconnect the TCM (just the module, not the CVT of course) to the F-CAN communication line. My hopeful reasoning is that this would allow the BCM/MICU, the Gauge module, and the multipurpose camera to "think" the TCM is there and connected. If I connect the wires to the TCM for the F-CAN lines, for +B power, a wire to for ATP-P (parked position - grounded out elsewhere) and for TCM Ground, would that be sufficient? Would the TCM actually communicate anything in the F-CAN line then? And would the information it communicates suffice for the other systems to work, or would its information just cause other problems? The TCM would obviously not be connected to all the other sensors on the CVT (CVT speed sensor, CVT driven pulley pressure sensor, torque converter turbine speed sensor, etc.). Perhaps most significantly, the TCM would not have its PT-CAN communication line with the PCM, since I've had to swap to a MT's PCM. Would these absences render the TCM unable to be detected via the F-CAN lines by the other modules?

The last part of this very long problem is regarding the permanent nature of these permanent DTCs. I'll admit, I have already attempted to reconnect the TCM as I outlined in the above paragraph. And the result was no difference. However, because I had not pared down the TCM harness yet, it was still full of connectors, and I was unable to stuff everything somewhere in the engine bay such that I could close the hood. Therefore, I did not actually drive the car at all. I only started it up. All the alerts and errors remained the same. My understanding from what I've read about Permanent DTCs is that they are cleared by the vehicle itself only after the problem is detected to have been remedied and the car has driven some minimum distance and gone through some minimum number of warm up/cool down cycles. If this applies to the P-DTCs I have listed above as well, is it possible my experiment with reattaching the TCM actually worked but the car would have to be driven up to those minimums before I'd see the dash lights correct/clear? Or are the dash indicators supposed to clear immediately, only leaving the P-DTCs written on the vehicle's computer until self-cleared? I can certainly just try to pare down the harness and stuff it all in there and go for a drive, but I am hoping someone out there with a better understanding than me can give me some insight before I tear apart the TCM harness and render it otherwise useless.

Thanks in advance for any insights anyone has to offer.

 

You are on the right track.

Those other modules are expecting data from the TCM.

Plug the TCM back in and then clear all the various codes. The modules should then see the TCM. Not sure if the other modules will be happy if the TCM is throwing a fit about the transmission missing. Easy enough to test for.

You can also build a device to put the missing CAN packets on the bus. It's helpful you still have the TCM so you can sniff out the required packets to fabricate.

 

Thank you so much for the input. It’s helpful to know I’m not completely thinking in the wrong direction.

Would you be able to elaborate on what building such a device would entail? Is it mainly a matter of supplying a missing resistor between the H and L lines, or is there a lot more to consider?

Thanks again.

 

It's a lot more than just resistors.

You essentially have a small computer running code you write sending CAN data to the bus with a CAN interface. Sort of like a network card for your home computer but for CAN.

You can do a lot of neat things. The hardware is all off the shelf like an Arduino and a CAN bus shield. The programming and reverse engineering the CAN messages are a bit of a steep learning curve.

 

This is super interesting. For the moment, I'm stripping down the TCM harness and reconnecting the TCM in the car. I'll try driving it as such, but my suspicion is that it won't fix the problem yet. I suspect that with the permanent DTCs, I need to drive the car for the vehicle to determine that the problem is fixed. But driving the car is supposed to cause the TCM to send data that it would normally send if the CVT was operating. In my case, there will not be a CVT in operation, meaning the TCM will not receive the information that the CVT is in a drive gear, that the pulleys are moving at any particular speed, etc. As well, the TCM will not be receiving any communication from the ECU/PCM. The result I'm guessing is that the CAN data the TCM sends out will be abnormal. And the fault codes are triggered when either there is no data received by the asking modules for a specified time interval or when the data received is abnormal a certain number of times.

So if my TCM reinstall hack doesn't solve it, I may have no choice but to put together a device, as you say, that will send usable CAN data to the bus. I would somehow have to determine what that usable data looks like. And then write the code that will produce the appropriate data. There's a lot I have to learn to get there.

 

Don't forget to clear the stored codes. Drive cycles may or may not reset those codes.

Another option might be getting a copy of the eeprom for those modules from a MT version and then writing that data to your modules.