Outlander CMU CAN

[xp677]

Hi guys,

I'm currently running an Outlander pack for my project, I have CAN communication between my BMS and the 10x CMUs from the Outlander.

I have removed the ANO wiring from the CMU harness as I don't have the Outlander BMS.

I have shortened the CTR (termination resistor) wiring from CMU #7, and spliced it into the CANH/L wiring near to the connector for this CMU.

My BMS communicates through a MCP2515, 16MHz crystal, and a MCP2562 transceiver. My microcontroller is a Teensy 3.2.

My initilisation code is below:

Code: Select all

MCP_CAN CAN3(20);

void setup_cmu_can3()
{
  if (CAN3.begin(MCP_ANY, CAN_500KBPS, MCP_16MHZ) == CAN_OK)
  {
    can3_good = 1;
    CAN3.setMode(MCP_NORMAL);
  }
}

My communication code uses the INT function of the MCP2515:

Code: Select all

byte cmu_len;
byte char cmu_incoming[8];
int cmu_id;

    if (!digitalRead(16))
    {
      for (int x = 0; x < 8; x++)cmu_incoming[x] = 0;
      CAN3.readMsgBuf(&cmu_id, &cmu_len, cmu_incoming);
      Serial.print("CAN: 3"); ;
      Serial.print(" ID: ");
      Serial.print(cmu_id, HEX);
      Serial.print("  DLC: ");
      Serial.print(cmu_len);
      Serial.print("  Data:");
      for (byte i = 0; i < cmu_len; i++)
      {
        Serial.print(cmu_incoming[i]);
        Serial.print(", ");
      }
      Serial.println();
    }

With a single CMU connected, everything works as expected. I can decode the CAN message into mV readings for each cell, and they match my multimeter readings.

However, when connecting a second CMU, the data changes to read "255,253" for each voltage reading. This does not appear to be corruption - the values are consistent. It almost looks like an error state from the CMU.

Does anyone have any suggestions here? Have I messed something up with either the wiring or the code?

[tom91]

The main question should be, you get any new can IDs when you connect the second CMU.

It looks like it due to the xAx and xBx messages.

if you have a known good can decoding tool, always useful to have use that to see what is really on the bus.

[xp677]

Ahh yes, sorry I should have added that in the image there are two CMUs connected. If I disconnect one, then I get "normal" information from the other.

I don't have access to any decoding tools - the nature of these messages does look as though they are coming through as intended. If I connect 10x CMUs, then I seem to get a mixture of "good" and "bad" ones. So I do think there is some sort of conflict there.

Though as far was I was aware, the CMU only receives data on address 0x3C3, I am transmitting all zero on that.

[xp677]

Quick update, I grabbed an arduino with a CAN shield and connected it up. It seems that once a CMU starts sending this "bad" data, it's not possible to get it back to normal. I connected it to a single CMU which was previously giving correct voltage readings, now all I get is the 255,253 repeated over and over.

So, it looks like something I've done has bricked a number of CMUs. Which is odd because, shortly before connecting them all up, I tested them all one-by-one to get the CAN ID from them, and all of them worked fine.

[tom91]

you have the propper can termination resistors on the network?

[xp677]

I'm using the internal termination from the CMU which is on the longest cable from the Outlander harness. I have termination in my unit, see attached schematic (note IC10 has incorrect value, actual is MCP2562).

For the images above, I am running 2x CMU only. Termination on the furthest one.

[xp677]

I'm having a dig in to the ANO wiring between the cells, From what I can tell, this is used, in conjunction with the Outlander's BMU and the Mitsubishi scan tool, to renumber / readdress the cells. With the CMUs daisy-chained, they could use this system to self-address, and pass this info to the next CMU for it's self-addressing.

http://mitsubishi.automotive-manuals.co ... 00ENG.html

http://myimiev.com/forum/viewtopic.php? ... 2&start=15

I have completely removed that ANOO and ANOI wiring from the CMU connectors, the only thing going into the 8-pin JST connector on the CMU is the original 12V, GND, CANH, CANL. On the furthest CMU, I've connected the CTR1 and CTR2 pins in parallel with CANH and CANL, which is electrically the same as how it was wired from the factory. I have not used a long cable from the junction for this, however, and have spliced into CANH and CANL near to the CMU.

At this point, I have a random selection of happy and unhappy CMUs. I can plug a happy CMU directly into an Arduino with a CAN shield, and all is good, I can then plug that same cable into an unhappy CMU, and get the messages posted in the images above.

[xp677]

An update on this, it appears that this is some battery-voltage related state. Perhaps the CMU cannot accurately read the voltage on the cells. I connected a 24R resistor across an unhappy pack and it the CMU immediately started outputting the "normal" CAN data. A few moments after removing the resistor, it went back to the "default" of 255,253 for each cell.

This is curious, because this only became an issue once I connected multiple CMUs to the network. I had previously had 3 or 4 separate packs sitting on my dsek and all worked fine for hours. I'm not sure why they are so picky all of a sudden.

This doesn't seem to be due to any voltage reference between the packs - connecting multiple packs together in series does not correct this issue. But putting a load on the pack does.

[tom91]

remove the termination and just have one 120 resistor at your decoder.

[xp677]

I've tried that. Same result.

There is nothing to suggest that the CAN data is invalid or experiencing errors in communication.

[tom91]

Okay, what are the cell voltages at?

Also can you show a picture of your setup?

[xp677]

Cell voltages are at 3.9V from multimeter, I'm not using a unit which parses the CAN right now so don't know what that is reading. From the screenshots below, it looks like ~3875mV.

One of my setups is here:



You can't see it in the photo, but the pack shown has a separate wiring setup going to a BMS in the car, the mess of wiring posted here is intended for a second pack. both wiring setups give the same result. Termination resistor or not, same result.

I've tried 3 setups now: My circuit from the schematic posted earlier, the setup in the photo, and a Raspberry Pi with Wireshark. All give the same readings.

This screenshot is from a happy and unhappy CMU:



And this one is from a few moments later, after connecting a resistor across the terminals of the unhappy CMU's pack:



As before, when removing the resistor, the pack remains happy for a few seconds, then goes back to sending the data as in the first screenshot.

[boekel]

The picture shows a 4 wire connection: so without terminator resistor in the CMU used.

to terminate: use 6 wire plug (originally: 8 wire) and connect the second pair to the canbus (on the second pair there is a resistor in the CMU

The errors you describe are exactly what happens when the bus is not terminated correctly, one unit sometimes works, but with long wiring like in the picture, you need at least one 120 ohm resistor, and best to have two.

you can measure the actual resistance with a multimeter when the CANbus is off.

[xp677]

That doesn't make sense - I can connect one unit, and it will work fine, then connect a different unit, and it won't work at all. Same cables, same bus, same termination.

The good units are good, and the bad units are bad. Since all the CMUs are identical apart from their CAN address, doesn't this rule out bus issues?

I can see CAN errors manifest in a number of ways, but complete data packets with repeated values in the correct places doesn't look like one.

I have previously wired it as you describe, with the termination pins of the CMU connected in parallel. No difference.

Resistance on the bus is 60 ohms as expected, when both ends are terminated. Or 120 ohms with just the receiver terminated. Or 120 ohms with just the CMU terminated.

Terminating the bus or not, it doesn't make a difference. Some CMUs output valid voltage data all the time, others only output valid data when the voltage changes.

Note that all CMUs (even the "bad" ones) output the temperatures correctly on address 6#1.

[boekel]

Ok, other idea: check if first and last celltap have connection with cell, put a nut on it to be sure, and disconnect the big connector when doing this.

(by the way: always disconnect the big connector when working on the modules, the CMU's are easy to break)

do disconnect connector, check / fix celltaps, than plug in big connector, than CANbus.

[xp677]

Yes, that was the issue. The nuts on the first and last cells were finger-tight where I had previously removed the bus bars.

Even though this had continuity with the multimeter, the CMU was not happy until I tightened the nut down harder, and it took a few seconds to update.

When I added the load resistor, I imagine that the pressure from the resistor wiring was enough to increase the contact.

So now we know.

I tightened +ve first, this didn't fix it until I tightened -ve as well. Likely it just needs -ve as a reference. The "255,253" message is either a message, or the result of an internal pullup, etc.

Many thanks for the advice! It's all too common that we jump to the more complex solutions, without considering the simple ones first.

What amazes me is that every pack worked fine on the bench for days or weeks at a time, with the nuts just as poorly tightened as they are now.

Thank you for the advice on disconnecting the CMU while doing this.

[tom91]

Wait, this was not mentioned, also one of the biggest issues is a loose connection.

As there are so many internal checks between different cells just one loose connection can cause the module to throw out garbage.

Good thing you found out it was the 'easiest' fix.

[xp677]

Of course it wasn't mentioned, if I'd known about it, I'd have mentioned it. For all I knew, the connections were tight enough - since the CMUs had been responding properly on the bench, and I hadn't touched the terminals since then.

It seems that nobody hes experienced this before, so it's good to know the cause.

Regarding the checks, why didn't you start with this? I've not found information anywhere on the CMU response for missing/loose connections. There are DTCs from the Outlander for such things, but nobody has linked CMU output to this. All I knew for sure is that if the CMU is disconnected from the pack, it won't output CAN data at all.

[tom91]

Loose connections, you will unfortunate learn really quick that even if it reads alright sometimes does not mean it is right/works all the time.

I was under the impression that you had taken the module out of the pack and then had issues not that you had the bus bars off the modules and then had issues, but now we all know that loose connections are bad.

Luckily you have a bolted BMS connection, this happens on Tesla modules, from the Mercedes B class particularly and writes off a whole module as the are really hard to get mounted back propperly.

[xp677]

I was under the impression that you had taken the module out of the pack and then had issues not that you had the bus bars off the modules and then had issues

Wait, what's the difference? You need to take the bus bars off the module before you can get it out of the pack!

[xp677]

A quick update on this.

The original issue was due to an incomplete connection on the negative-most terminal. This caused all cells to show as 65533mV.

However, should any other connection be interrupted, the cell in question will show this incorrect reading independently. This would be the case should one of the CMUs onboard fuses be damaged.

I had a single cell in my system which was reading at 65535mV, looking inside the CMU revealed that the fuse for this cell was missing! I'm not sure how that occured, there is no evidence of a fuse ever being fitted, there were just bare HASL coated pads. There was also no fuse or fuse fragments within the casing. A replacement fuse solved this issue.

Another thing to note is that the older CMUs (those fitted to the "blue" lithium cells) have 10 channels of voltage readings. I'm not sure why, as I am not aware of a LEV40-10 pack in any vehicles. However, this is a convenient source of spare fuses! The newer "green"-celled packs do not have the extra fuses fitted.

Fuses are 72V, T1A, 1206 package. They didn't look easy to obtain in the UK, however 63V ones are plentiful.

[PatrykS]

Fuses are 72V, T1A, 1206 package. They didn't look easy to obtain in the UK, however 63V ones are plentiful.

I found them on eBay.

[steveknox]

I found them on eBay.

Care to share a link?

[PatrykS]

It was AliExpress:
https://www.aliexpress.com/item/3286250 ... 4c4dg8jsK7