WinterDragoness
Member
Two breakthroughs to report...
One is that after a lot of sleuthing through log files and comparing messages I sent to values found in corrupt OTP memory, I'm now 99% sure I understand what RS485 commands broke my TWCs.
Tesla segments OTP memory into blocks of 16 values where each value is a 16-bit number like 0xFFFF. Normally, block 1 holds the TWC model number in ascii values: EVWTS80HL
Block 2-5 are unused and remain set to all FFFF values.
Block 6 contains what I think might be a date and place of manufacture code and TWCID (9393 in this case): A17I0039393
Block 7 and higher are unused and remain set to all FFFF values.
It appears that during boot, the firmware looks at Block 4 first. If it finds non-FFFF values, it uses that as the model number. If not, it looks at Block 3, then Block 2, etc. Normally it must scan down to Block 1 to find a valid model number. With my corrupt OTP, it finds all 0000 values in Block 4 and uses that as the model number. This puts it in an odd state where it's stuck in Master mode and won't charge a car.
The firmware also looks at Block 16 for TWCID. If it finds all FFFF, it checks Block 15, 14, etc, and normally finds the TWCID in Block 6. If it finds all 0000 data it actually doesn't break - it somehow interprets the 0000 values as TWCID EB30, at least in protocol 1.
The RS485 command FC19xxxx looks at OTP Block 6, then 7, then 8, etc. When it finds a block that does not contain all FFFF values, it writes the data contained in xxxx to that block (expanding 8-bit values to 16-bit). The TWC then either freezes, or responds with an FD 19 01 00 00 00 00 00 00 00 00 00 00 message. I don't know why it freezes sometimes. So basically, FC19 lets you permanently write a new TWCID and date of manufacture. The new TWCID is not loaded until TWC is reset or power cycled. If the TWC reads up to Block 16 and finds none have all FFFF values, FC19 does nothing. Oddly, it still returns FD 19 01 ... as if the write were successful.
The RS485 command FC1Axxxx looks at OTP Block 1, then 2, then 3, then 4. If it finds a block that does not contain all FFFF values, it writes the data contained in xxxx to that block (expanding 8-bit values to 16-bit). The TWC responds with an FD 1A 01 00 00 00 00 00 00 00 00 00 00 message if it found a block to write to, otherwise it responds with FD 1A 00 .... Basically, FC1A lets you permanently write a new model number. Unfortunately, if you don't write a valid model number, next time the TWC is reset it enters that broken state where it won't charge a car. Once you've called FC1A 3 times and blocks 1-4 are filled, you're screwed if block 4 doesn't contain a valid model number. This is the state I'm in on two TWCs. OTP memory can not be altered once a value is written because each bit set to 0 basically blows up a tiny capacitor that creates a permanent short that represents a value of 0 instead of 1. I tried manually burning a model number into Block 5 using the JTAG interface but it did not fix the problem, so apparently the firmware doesn't look at Block 5.
I think the only reason I didn't break my TWC early on in testing sequential undocumented messages is that I always tested FC19 before FC1A, and FC19 happened to freeze it in those cases, which prevented FC1A from doing anything.
The second thing I have to report is I was able to burn the firmware from my broken protocol 1 TWC to a working protocol 2 TWC. This turned my working TWC into a protocol 1 TWC which lets me stop the car from charging by simply setting the amps to 0. It also changed the TWC's ID from 9399 to 018F. I tried the same with my broken protocol 2 TWC and its ID changed from 9393 to 0189. Notice that 9399 - 9393 = 6 and 018F - 0189 = 6. This lends credence to the theory that protocol 1 and 2 firmware get the TWCID from the same place in OTP memory but each interprets it differently. I suspect the fact protocol 1 firmware doesn't read 9393 correctly is actually a bug, but not one that necessarily breaks anything.
It would be great if everyone could put protocol 1 on their TWC and solve the problem of stopping cars from charging, but unfortunately it requires buying at least $50 of equipment and some software setup that isn't trivial. I'm also worried that Tesla will eventually update the TWC firmware to protocol 2 through the connection to the car. I might be able to block firmware updates with a hack to the firmware version number.
One is that after a lot of sleuthing through log files and comparing messages I sent to values found in corrupt OTP memory, I'm now 99% sure I understand what RS485 commands broke my TWCs.
Tesla segments OTP memory into blocks of 16 values where each value is a 16-bit number like 0xFFFF. Normally, block 1 holds the TWC model number in ascii values: EVWTS80HL
Block 2-5 are unused and remain set to all FFFF values.
Block 6 contains what I think might be a date and place of manufacture code and TWCID (9393 in this case): A17I0039393
Block 7 and higher are unused and remain set to all FFFF values.
It appears that during boot, the firmware looks at Block 4 first. If it finds non-FFFF values, it uses that as the model number. If not, it looks at Block 3, then Block 2, etc. Normally it must scan down to Block 1 to find a valid model number. With my corrupt OTP, it finds all 0000 values in Block 4 and uses that as the model number. This puts it in an odd state where it's stuck in Master mode and won't charge a car.
The firmware also looks at Block 16 for TWCID. If it finds all FFFF, it checks Block 15, 14, etc, and normally finds the TWCID in Block 6. If it finds all 0000 data it actually doesn't break - it somehow interprets the 0000 values as TWCID EB30, at least in protocol 1.
The RS485 command FC19xxxx looks at OTP Block 6, then 7, then 8, etc. When it finds a block that does not contain all FFFF values, it writes the data contained in xxxx to that block (expanding 8-bit values to 16-bit). The TWC then either freezes, or responds with an FD 19 01 00 00 00 00 00 00 00 00 00 00 message. I don't know why it freezes sometimes. So basically, FC19 lets you permanently write a new TWCID and date of manufacture. The new TWCID is not loaded until TWC is reset or power cycled. If the TWC reads up to Block 16 and finds none have all FFFF values, FC19 does nothing. Oddly, it still returns FD 19 01 ... as if the write were successful.
The RS485 command FC1Axxxx looks at OTP Block 1, then 2, then 3, then 4. If it finds a block that does not contain all FFFF values, it writes the data contained in xxxx to that block (expanding 8-bit values to 16-bit). The TWC responds with an FD 1A 01 00 00 00 00 00 00 00 00 00 00 message if it found a block to write to, otherwise it responds with FD 1A 00 .... Basically, FC1A lets you permanently write a new model number. Unfortunately, if you don't write a valid model number, next time the TWC is reset it enters that broken state where it won't charge a car. Once you've called FC1A 3 times and blocks 1-4 are filled, you're screwed if block 4 doesn't contain a valid model number. This is the state I'm in on two TWCs. OTP memory can not be altered once a value is written because each bit set to 0 basically blows up a tiny capacitor that creates a permanent short that represents a value of 0 instead of 1. I tried manually burning a model number into Block 5 using the JTAG interface but it did not fix the problem, so apparently the firmware doesn't look at Block 5.
I think the only reason I didn't break my TWC early on in testing sequential undocumented messages is that I always tested FC19 before FC1A, and FC19 happened to freeze it in those cases, which prevented FC1A from doing anything.
The second thing I have to report is I was able to burn the firmware from my broken protocol 1 TWC to a working protocol 2 TWC. This turned my working TWC into a protocol 1 TWC which lets me stop the car from charging by simply setting the amps to 0. It also changed the TWC's ID from 9399 to 018F. I tried the same with my broken protocol 2 TWC and its ID changed from 9393 to 0189. Notice that 9399 - 9393 = 6 and 018F - 0189 = 6. This lends credence to the theory that protocol 1 and 2 firmware get the TWCID from the same place in OTP memory but each interprets it differently. I suspect the fact protocol 1 firmware doesn't read 9393 correctly is actually a bug, but not one that necessarily breaks anything.
It would be great if everyone could put protocol 1 on their TWC and solve the problem of stopping cars from charging, but unfortunately it requires buying at least $50 of equipment and some software setup that isn't trivial. I'm also worried that Tesla will eventually update the TWC firmware to protocol 2 through the connection to the car. I might be able to block firmware updates with a hack to the firmware version number.
Last edited:
