Unexpected Behavior and Check Engine Light

[radensb]

@rampage128

I downloaded this project and loaded it to an Arduino with the MCP2515 shield and connected it to the car. before I turned the car on, I noticed that the door chime stopped when connected to the OBDII port, as if something was communicated on the CAN Bus and stopped the chime.

I powered on the car and noticed the following:

1. The check engine light came on immediately. I used my OBDII reader with Torque to pull the codes and got a U0164 code which is "Lost Communication With HVAC Control Module".
2. Tire Pressure Indicator turned on.
3. Ignition Start/Stop switch malfunction. I could not get the car to start with the unit plugged in. Once I removed it, I could start the car, but pushing it again would not stop it. 4. Engine rev'ed a bit high in idle and felt rough. Not related. edit 5) The radiator fan seemed to spin up to max RPM with the car in ON. The engine temp was at room temperature. edit 6) The gear indicator disappeared from the dash. *edit 7) VDC Off, Traction Loss, ABS lights turn on.

I cleared the code and the Check Engine light went away, but the issues above persisted. I drove the car around the block and then things seemed to return to normal.

I knew that messing the the CAN Bus was a bit risky, but I have looked through your code and cannot understand why this happened. Could this be because I still have the car intact and need to remove the existing control interface before using this? As in, did I create a conflict by having two control sources? I wanted to test this out with a basic case. I simply wanted to send (via serial) the command to cycle through the AC Modes by sending 0x7B 0x63 0x07 0x7D.

[radensb]

I tried removing the radio/AC control panel and tried again. As soon as the Arduino CAN adapter is connected, it seems that the CAN Bus gets interrupted and doesnt recover until the adapter is removed and the car is driven for a bit.

Still no luck.

[rampage128]

Thx for the detailed report.

The error code is sent by the AC auto amp and typically occurs, when the signals from the HVAC Control Module are missing from the can bus. Unfortunately it seems that the error U0164 triggers the emergency mode of the ECU, which explains 1., 2. and 3. of your error list.

My 370 is a german model and uses a very outdated CD navigation unit installed in the trunk. So my AC auto amp does not produce this error code, even if the control unit is missing. So unfortunately I cannot give you exact information on how to fix it.

You can check the following general reasons to why the module may not be able to connect:

1. Check that you have the jumper set to enable the termination resistor on the MCP2515. Without that the unit cannot communicate with the car.
2. Connect your arduino to a can-sniffer to check if it actually sends the required can-packages successfully.
3. Make sure your OEM HVAC control module is not connected, when connecting the arduino to the car, because they will both send the same signals and confuse the AC auto amp.

If the above measures do not fix your issue, then it might be that in "newer" versions of the AC auto amp like yours the can messages are different. Then you will need to check the communication between your AC auto amp and OEM HVAC control module using a can-sniffer, to verify that the protocol is identical to what the arduino sends.

Unfortunately I can not test this myself, because I have no access to a car with your version of the AC auto amp and HVAC control module.

[radensb]

@rampage128

Thanks for the reply. I made some progress here. Turns out that my MCP2515 shield has a 16MHz oscillator on it and the code was written for an 8MHz oscillator. Once I changed that, I stopped getting the unexpected behavior. I guess I was corrupting the crap out of the CAN bus and the car stopped functioning properly. :)

Check that you have the jumper set to enable the termination resistor on the MCP2515. Without that the unit cannot communicate with the car.

I noticed that my CAN shield doesn't have provisions for a termination resistor. I think this is only needed if I remove the last device on the CAN chain. Unfortunately, I don't know what device that is. If its the AC controller, I may have to add one.

Connect your arduino to a can-sniffer to check if it actually sends the required can-packages successfully.

I think it is, but this would be good to check anyway.

Make sure your OEM HVAC control module is not connected, when connecting the arduino to the car, because they will both send the same signals and confuse the AC auto amp.

This is definitely an issue and what I am actively looking to resolve. When the Arduino is connected in addition to the OEM HVAC controller, there is a definite conflict as I can see the Mode toggling between modes, the temp toggling between temperatures (in C and F units), etc. It's also difficult to send commands as it seems they get immediately overwritten by the OEM controller sending the same command with different data. Is the HVAC controller the actual physical control plate with the AC knobs and radio buttons?? I actually disconnected the physical, but I still got what appeared to be a conflict, so perhaps the Head Unit is actually sending the commands and just getting control state from the control panel? The car does remember your AC settings between power ups, so perhaps that is also a factor?

I noticed that in your setup, you removed everything in the console (including the stock head unit I believe?). Perhaps I can try again with the head unit also removed to see if I can get steady control. I did sniff the 0x54A and 0x54B commands and confirmed that the data definitions matched what is defined in niscan_dfs.h so the protocol is the same.

I see in the code some constants that I am unclear about. In niscan.cpp:NisanClimateCOntrolCanConnector::writeCan(MCP_CAN): `can->sendMsgBuf(0x540, 0, 8, reinterpret_cast<INT8U>(_can1.getData())); can->sendMsgBuf(0x541, 0, 8, reinterpret_cast<INT8U>(_can2.getData())); can->sendMsgBuf(0x542, 0, 8, reinterpret_cast<INT8U>(_can3.getData()));`

Are 0x540, 0x541, and 0x542 PID's? What is happening here? Do you have a list of the PID's that you are using and their function?

[rampage128]

Turns out that my MCP2515 shield has a 16MHz oscillator on it and the code was written for an 8MHz oscillator.

Hah true. I cheaped out on that because I wanted to save money in case it would not work out. :-P Maybe it makes sense to make that a configurable option somehow.

my CAN shield doesn't have provisions for a termination resistor. I think this is only needed if I remove the last device on the CAN chain.

My model does not have can lines running in the dashboard, so I made myself an OBD adapter. There I need the resistor. When you grab the signal from within the bus, it should usually work without. Just sometimes it doesn't.

I actually disconnected the physical, but I still got what appeared to be a conflict, so perhaps the Head Unit is actually sending the commands and just getting control state from the control panel?

Yes, the head unit is the brain of the operations. In the worst case you will have to get rid of the whole headunit. You can try that by pulling the two CAN pins from the head unit plug and trying to operate it ... but I am pretty sure the head unit will show an error without a can signal.

Are 0x540, 0x541, and 0x542 PID's? What is happening here? Do you have a list of the PID's that you are using and their function?

So the 0x54A, 0x54C ... are the signals coming from the AC auto amp. It is the signals which tell the head unit which temperature/fan speed/ac compressor is actually active.

0x540, 0x541, 0x542 is the signals the head unit sends to the AC auto amp to request state changes. It is a mix of flags that switch once you press a button and two values for temperature and fan speed.

I will try to add some documentation on the CAN packets to the readme ASAP.

[radensb]

The issues with my setup are now understood and corrected. Closing this.