Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Error Messages Lists

This site may earn commission on affiliate links.
I have noticed these 2 areas with a list of Roadster error messages:

Open-Vehicle-Monitoring-System/ovms_server_tr.vece at master · openvehicles/Open-Vehicle-Monitoring-System · GitHub

Roadster VDS Messages

Perhaps there is another located elsewhere more complete?

However there are quite a number of error messages that do not appear on these lists. Don't get me wrong on this I am extremely grateful for all the work that has gone to make these. We just need a leak on this from Tesla on this. I don't really get why the error/notification list in not in the public domain...

I notice that (in my case anyway) I have had a number of error messages that don't appear on these lists. Namely:

63, 1055, 1056, 1057, 1065, 1131, 1141, 1538, 1546, 1661, 3018....

If anyone has a full list we should make it available to all...
 
There is a way of getting the full list:

Using a USB-to-CAN adaptor, inject the error code into the bus, and see what comes up on the VDS. Really not hard to do, but scary because I don't know if that is (a) written to the logs, and (b) reported to Tesla. For completeness, it should also be done with debug message mode on/off.

These are also in the VDS firmware dumps if somebody wants to do some reverse engineering.

I haven't seen a full list. Happy to accept git push updates to the OVMS list if anybody has anything better.
 
If someone has a dump of the firmware, a "strings" command should do it, no?

Perhaps not.

Hypothetically speaking, all the messages could be in there, but there could be a separate structure / control logic tying the message test to message number and normal/debug information switch. Hypothetically speaking, that would require some code disassembly. o_O
 
Perhaps not.

Hypothetically speaking, all the messages could be in there, but there could be a separate structure / control logic tying the message test to message number and normal/debug information switch. Hypothetically speaking, that would require some code disassembly. o_O
True, but we should be able to find all the message texts. Associating them to the message number might be difficult, but at least you'd know what questions to ask...

Then again, if the current list of messages were, hypothetically speaking, complete, perhaps further association of message number to message text could be more difficult. Interesting idea of injecting the errors via the CAN bus. Could be a good use for a "salvage" titled car, or one that's been mechanically totaled but is otherwise electrically intact. Do you think there would be enough points to poke and prod, where one could reverse engineer the system? (Thinking more along the lines of Compaq's historic cloning of the IBM PC BIOS, vs an invasive disassembly of the code.)
 
Do you think there would be enough points to poke and prod, where one could reverse engineer the system? (Thinking more along the lines of Compaq's historic cloning of the IBM PC BIOS, vs an invasive disassembly of the code.)

Hypothetically speaking, I don't think it would be difficult. Just time consuming. The CAN bus injection method could be used to verify results (and that is trivial).
 
Check your PDF's formatting. It appears jumbled on my end.

Also, where did you submit your list because I have around 100 more IDs, messages, etc. to add.

PDF was done with a Mac... so I wonder?
anyway...
Pete would you contribute you numbers so I could add them? I had the VDS list from the forum here and checked with the github one....
I would post the new one then in TXT format so it would be editable for everyone...
 
IMG_20181010_154759.jpg
 
I am having a go at the can-bus injection method mentioned above. I am using the VDS from a salvaged car and an OVMS-module for the investigation.

First I toyed around issuing "can can1 tx standard 100 93 01 B3 B4 00 00 00 00" to raise an alert and "can can1 tx standard 100 93 00 B3 B4 00 00 00 00" to clear it. B4B3 represents the alert ID. I find that ID <= 3500 either results in the alert message "Unrecognized Alert ID" or something else meaningful (or at least less generic), while for 3500 < ID < 65535(=0xFFFF) I observe the message "Alert ID out of range". I have only probed the latter range near its boundaries and at a small handful of IDs in between. The message text suggests that this range is void of anything interesting, but that is only a hypothesis for now. ID=65535 does not raise an alert. There seems to be no response to that ID.

The above finding suggests that any new messages should be sought in the interval from 0 to 3500 inclusive. I have done that. I have automated (somewhat) the procedure of raising and clearing alerts. For this purpose I raise an alert by "can can1 tx standard 100 93 05 B3 B4 00 00 00 00" as that causes the alert window to disappear without tapping the display after it is cleared.

Known alerts are documented in
There are 748 known ID codes. The latter source contains them all.
I have checked the other 2753 IDs in the interesting range.

The following IDs result in orange message "Unrecognized Alert ID" both in enduser and debug mode:
11-12, 15, 17-18, 20, 22, 24, 26, 33-42, 44-49, 64-89, 109-256, 289-397, 417-419, 421-427, 431-499, 505-524, 540-546, 548-559, 562-599, 614-699, 704-719, 736, 738, 740-879, 890, 892-900, 1157-1159, 1168, 1175-1199, 1224-1399, 1436-1439, 1445-1446, 1449, 1454, 1476-1489, 1498-1521, 1523-1531, 1566-1639, 1672-1899, 1909-2002, 2043-2046, 2049, 2052-2060, 2063-2064, 2067-2069, 2082-2085, 2097, 2100-2399, 2401-2409, 2424-3000, 3034-3077, 3079-3142, 3145, 3147-3500
The procedure was mindbogglingly boring making it a bit difficult to keep focus. Hence I can not totally rule out that I have overlooked a deviant message, but I believe that I haven't.

The remaining IDs are (id, colour, enduser, debug):
5, orange. Debug-Only Message, "VMS Watchdog"
3033, blue , ",", "("
3078, blue, "Unrecognized Alert ID", "" (Saying Debug-Only Msg)
3143, blue, "", "Unrecognized Alert ID"
3144, blue, "", "Unrecognized Alert ID"
3146, blue, "", "Unrecognized Alert ID"

For ID 3033, the characters appearing were not entirely repeatable. I provoked a yellow 2418 "Memory allocation below the heap" while investigating.
I experienced spontaneous reset and a yellow ID 2412 "VDS: Data abort exception" while investigating 3143. I don't know if there is a bug, if I just took the VDS too far outside its intendend use or if there is something wrong with it.

Next steps could be
- verifying known codes
- investigating IDs with results suggesting that the alert screen is intended for modification by subsequent can messages, i.e. the blank(ish) screens and some already known messages with incomplete sentences
- trying to understand more about the can-bus messages to the VDS
 
  • Helpful
  • Informative
Reactions: Roadster and markwj
I am having a go at the can-bus injection method mentioned above. I am using the VDS from a salvaged car and an OVMS-module for the investigation.

Feel free to eMail me at mark (at) openvehicles (dot) com. I have a lot more information on this now (compared to the early days of this), as well as a much better understanding of the functioning of that '100 93' message. The code->message is hard coded in the VDS (although there is a cool way of adding custom messages).