Model 3 PCS Communication Issue (Continued from closed support thread)

[P.S.Mangelsdorf]

Has anyone tested Damien's PCS controller with a model-Y PCS? I have a model-Y PCS and would like to know whether or not this controller can work with it before I make an order.

What's the part # on your PCS? I'll see if its the same as either of my model 3 PCSs (one functioning, one I broke).

To the best of my knowledge, the Y and 3 are essentially the same car with different sheet metal, up to a point where they started re-engineering the Y for the structural battery.

[asavage]

When working with Tesla parts, the CAN MsgIDs and payloads have changed at some firmware updates, which complicates answering the question, "will the same hardware from the same vehicle MY still work with Damien's codebase". I believe he's already worked around one or two FW revisions in his sofware, but there may be more variants extant.

[caymanS]

What's the part # on your PCS? I'll see if its the same as either of my model 3 PCSs (one functioning, one I broke).

To the best of my knowledge, the Y and 3 are essentially the same car with different sheet metal, up to a point where they started re-engineering the Y for the structural battery.

Here's a photo of serial/part number:
A quick note: I am now able to turn on DC-DC converter using Arduino Due code that Damien has provided. I am receiving error code 24-VCFront. I had many more errors in the beginning which I resolved except for this one. I could not find any DBC file that interprets PCS log message 0x424 to explain why VCFront is unhappy. Any lead would be appreciated.

[caymanS]

In this video, Damien uses a DBC file that interprets all error messages in CAN message id 0x424. I have searched a lot in the internet but just cannot find this particular DBC file. I have found three DBC files for Tesla model 3, but none of them include message 0x424. Does anyone know about this DBC file that Damien uses? It would be super useful for me to debug what's wrong with VCFront.

[asavage]

It's not a DBC, but a spreadsheet. On his Github for the Tesla-Model-3-Charger, under "PCS_CAN_Listing.ods". Direct link: https://github.com/damienmaguire/Tesla-Model-3-Charger/raw/master/PCS_CAN_Listing.ods

It opens to the third worksheet. Select the first worksheet, "All Msgs", and there's your 0d1060 (0x424). DBC files have all IDs listed in decimal (whether that's in the $$$ SAE spec or just convention, IDK).

[Marvin the Paranoid Android Voice Deep Thought Voice] "You're really not going to like it", though.

[caymanS]

It's not a DBC, but a spreadsheet. On his Github for the Tesla-Model-3-Charger, under "PCS_CAN_Listing.ods". Direct link: https://github.com/damienmaguire/Tesla-Model-3-Charger/raw/master/PCS_CAN_Listing.ods

It opens to the third worksheet. Select the first worksheet, "All Msgs", and there's your 0d1060 (0x424). DBC files have all IDs listed in decimal (whether that's in the $$$ SAE spec or just convention, IDK).

[Marvin the Paranoid Android Voice Deep Thought Voice] "You're really not going to like it", though.

Thanks for the spreadsheet. Unfortunately it does not say much, it only says the message is for PCS log, with no interpretation of message contents. In the video, Damien clearly mentions a DBC file that he uses with Savvycan.

[asavage]

Yeah, I had to back the vid up a bit to hear what you meant. I can't find a DBC for Model 3 that contains 1060 either (though I did finally find one that has 932: https://github.com/thezim/DBCTools/blob ... model3.dbc ), and other than Damien's reference to 0x424 in this post, nothing more.

[caymanS]

Yeah, I had to back the vid up a bit to hear what you meant. I can't find a DBC for Model 3 that contains 1060 either (though I did finally find one that has 932: https://github.com/thezim/DBCTools/blob ... model3.dbc ), and other than Damien's reference to 0x424 in this post, nothing more.

Thanks for the link. Here's the list of model-3 DBCs that I have found so far. They don't include message 0x424, but I am leaving them here in case someone finds them useful:
https://github.com/onyx-m2/onyx-m2-dbc/ ... model3.dbc
https://github.com/joshwardell/model3dbc
https://brianman.visualstudio.com/DBCTo ... n=GBmaster

[outlandnish]

OK thanks.

Hoping to check it out later today, could be some loose joints or stray solder, but I think I may know the issue, and it's dumb. I cleaned out the through holes for the capacitors with a tiny drill bit (my soldering iron and desoldering tool were having a hard time), and it may have walked more than I thought. Completely stupid on my part, this is why you don't work on EVs while overly tired.

Good news is I saw another PCS for an absolute steal, and it should be here by next weekend. That should let me confirm if its the PCS or something else going wrong.

Super late response, but I realized when trying to communicate with the PCS that my IPC lines were backward. The PCS IPC CAN RX line needs to go to the Controller's IPC CAN TX line (and the complement for the PCS IPC CAN TX). This confused me for a while until I looked at the Tesla schematics.

[outlandnish]

Thanks for the link. Here's the list of model-3 DBCs that I have found so far. They don't include message 0x424, but I am leaving them here in case someone finds them useful:
https://github.com/onyx-m2/onyx-m2-dbc/ ... model3.dbc
https://github.com/joshwardell/model3dbc
https://brianman.visualstudio.com/DBCTo ... n=GBmaster

The alerts for 0x324 and 0x424 are exactly the same - hope this helps!

[outlandnish]

Here's a photo of serial/part number:
A quick note: I am now able to turn on DC-DC converter using Arduino Due code that Damien has provided. I am receiving error code 24-VCFront. I had many more errors in the beginning which I resolved except for this one. I could not find any DBC file that interprets PCS log message 0x424 to explain why VCFront is unhappy. Any lead would be appreciated.

I'm running into similar issues. I have my own controller that's loosely based on Damien's (except uses an STM32F413 instead). I dumped the following info from the PCS over CAN:

Code: Select all

----------------------------------------
PCS Hardware Information:
  Part Number:    1135558-00-C
  Hardware ID:    0x00FC
  Component ID:   0x001B
  Build Type:     1
  Build Config:   0x019B
  PCBA ID:        0x04
  Assembly ID:    0x01
  Usage ID:       0x0001
  Sub-usage ID:   0xFFFF
  Platform Type:  3
  App CRC:        0x749B471F
  App Git Hash:   0x000000000000000
  Boot Git Hash:  0x0238F7BEA3E526B
  Boot UDS Proto: 5
  Boot CRC:       0xEFC3151B
----------------------------------------

I'm currently getting the following alerts:

Code: Select all

  
  Alert 24: PCS_a024_vcfrontMia
  Alert 30: PCS_a030_canRationality
  Alert 31: PCS_a031_uiMia
  Alert 107: PCS_a107_vcPcsDCDCInterfaceMia

I get a CAN rationality error related to the UI_ChargeRequest message (0x333) which looks to be be causing the CAN rationality error:

Code: Select all

PCS Alert 0x1E received
  Raw alert bytes: 1E 80 01 33 03 00 00 00
  CAN Rationality: ID=0x333 err=1
[1] ERROR: PCS_a030_canRationality

The CAN rationality errors goes away if I disable that message but I then still get PCS_a031_uiMia because I'm not sending that message.

I'm currently sending message 0x3A1 and 0x545 for VCFront. Incidentally, I noticed that the DBC I'm referencing marks the message as 0x221 (decimal 545 instead of hex). I wonder if that's a typo.

One other note in my exploration, my US based PCS still wanted the longer format message for 0x2B2. Sending the shorter variant message from Damien's firmware would throw a `PCS_a022_bmsMia`.

Does anyone have a hv controller to test against? Or potentially can send my way? Happy to debug this further.

PS: Also, typo on my previous message. I meant that PCS messages 0x3A4 and 0x424 have the same error messages. 424 is an individual alert notification. 3A4 contains all active alerts using two different pages (a mux) with bitfields for each alert.

[outlandnish]

Finally got access to a Tesla Model 3 to log against. I've resolved the `PCS_a031_uiMia` and `PCS_a030_canRationality` messages. They've added an extra byte to CAN message 0x333. I've also found two variants of the 0x2B4 Message that provide LV voltage on newer firmware and have it parsing properly.

I'm trying to sort out the `PCS_a024_vcfrontMia` and `PCS_a107_vcPcsDCDCInterfaceMia`. I've attached my traces here from the production Model 3 if anyone wants to inspect them.

I suspect the newer firmware is much more particular about the vcFront state matching up to the state reported by the PCS. I'm also wondering if I'm missing CAN messages (e.g. the 16V battery BMS via vcFront)

[outlandnish]

I think I've found what's going on with newer PCS firmware:

Since Tesla introduced the 16V battery, they changed up the messaging significantly to/from the PCS. Up until now, communication for the DCDC + Low Voltage charging happened with the vcFront_SystemStatus (0x3a1) message.

Now, it's been split into several parts. From https://tesla-can-explorer.gapinski.eu/?source=mcu3, I found that 0x441 and 0x443 control vc_pcsInterface and vc_pcsManagement (as well as the 0x3a1 vcFront_SystemStatus is significantly simpler and uses a mux). The signals are defined on that Tesla CAN explorer but I can't yet figure out how it's packed into each message.

Anyone interested in digging into those messages?

As a related note, I did figure out the message IDs Tesla uses for UDS based firmware updates to their ECUs as well as how to security unlock the ECU. If someone has a Tesla and wants to log re-deploying firmware. It might be an way to simplify some reverse engineering.