WinterDragoness
Member
I've finished decoding the 11 new commands in the new firmware. Although two of them are clearly intended to stop/start charge, they mostly just flip the main relays and fail to send a CAN message to the car telling it to start or stop. When the TWC stops charging, the ring around the car plug continues flashing green for ~30 seconds, goes blue for a couple seconds (presumably asking the TWC to resume charging), green for a bit longer, then red. After that, start charge command will not start charging again until you re-plug the car.
Basically, it looks like Tesla failed to test that stop/start charge actually works with a Tesla vehicle. WTF?? I can't really imagine how or why they could make such an error, especially since they had it working in firmware from 2016. My only possible theory is that maybe it somehow works with the newest Tesla vehicles but not with my 2014 car? Or they threw it in with no real testing because it's not used during normal operation? Or maybe it's like an emergency stop where they don't care if the car can be started again, but then why include a start command?
I put the TWC in legacy communication mode (DIP switch 2 off) and then I can successfully stop and start charge via the commands, but it's no more effective than ceasing communication with the TWC until the car stops charging. After some random number of stops, the car will refuse to start again until it's re-plugged. I also found the stop/start tests caused the car UI to change to a 30A limit instead of 40A at some point and it did not return to 40A upon re-plugging.
I ran tests using a 2017 TWC and a March 2018 TWC that the new firmware came with - both behaved the same. I also tried other things like setting the charge rate to 0A before stop charge and using the FCE7 command to reset the CAN network before stopping or before starting charge. Nothing made a difference.
None of the other new commands has anything to do with stop/start charging. The other nine commands will:
1) Enter a test state where all LEDs turn green and an orange LED in the middle stays on. Car will actually charge in this state, in which case the LEDs stream green but orange LED in middle remains lit.
2) Exit test state.
3) Return four bytes at memory location 8CF0 and 8CF1. These bytes are always zero in any state I could think to test.
4) Get state of the plug. Returns 0 when unplugged, 1 when charging, 3 when plugged in but not charging (for any reason, including error). It can also return 2 but I could not find a state where 2 was returned. Works with fake car in legacy communication mode as well.
5) Get firmware version including build number. Returns 4.5.3.2 with March 2018 TWC. Also returns TWCID of the unit. The old firmware version command returns only 4.5.3 and does not include TWCID.
6) Return (S)TSN plus the TWCID of the unit.
7) Return first 7 characters of VIN number of connected car. If DIP 2 is off (legacy communication mode) or fake car is plugged in, returns all zeros.
8) Return next 7 characters of VIN.
9) Return last characters of VIN.
So the new firmware still doesn't solve the stop/start charge problem or give us battery state. *sigh* But I can update TWCManager to display whether a car is plugged in or not, and to use the VIN number of the plugged car to stop/start the correct car using car API commands.
Nothing in the firmware checks if GPIO 34 is high or low, so it probably connects to a peripheral that does something when it's high or low. There is only one function in the latest firmware that does anything with GPIO 34: It sets GPIO 34 low as well as setting many other GPIO pins high or low, accesses a number of memory addresses of unknown function, and does something different depending on whether Serial Peripheral Interface A (SPI A) Status Register bit 0x20 is set or not.
What is your firmware version? You can find out using http://<raspberry pi address>/index.php?sendTWCMsg=FB1B&submit=1
If it returns 4.5.3, please get me the extended firmware version using: http://<raspberry pi address>/index.php?sendTWCMsg=FBEC7777<TWCID of slave>&submit=1
Basically, it looks like Tesla failed to test that stop/start charge actually works with a Tesla vehicle. WTF?? I can't really imagine how or why they could make such an error, especially since they had it working in firmware from 2016. My only possible theory is that maybe it somehow works with the newest Tesla vehicles but not with my 2014 car? Or they threw it in with no real testing because it's not used during normal operation? Or maybe it's like an emergency stop where they don't care if the car can be started again, but then why include a start command?
I put the TWC in legacy communication mode (DIP switch 2 off) and then I can successfully stop and start charge via the commands, but it's no more effective than ceasing communication with the TWC until the car stops charging. After some random number of stops, the car will refuse to start again until it's re-plugged. I also found the stop/start tests caused the car UI to change to a 30A limit instead of 40A at some point and it did not return to 40A upon re-plugging.
I ran tests using a 2017 TWC and a March 2018 TWC that the new firmware came with - both behaved the same. I also tried other things like setting the charge rate to 0A before stop charge and using the FCE7 command to reset the CAN network before stopping or before starting charge. Nothing made a difference.
None of the other new commands has anything to do with stop/start charging. The other nine commands will:
1) Enter a test state where all LEDs turn green and an orange LED in the middle stays on. Car will actually charge in this state, in which case the LEDs stream green but orange LED in middle remains lit.
2) Exit test state.
3) Return four bytes at memory location 8CF0 and 8CF1. These bytes are always zero in any state I could think to test.
4) Get state of the plug. Returns 0 when unplugged, 1 when charging, 3 when plugged in but not charging (for any reason, including error). It can also return 2 but I could not find a state where 2 was returned. Works with fake car in legacy communication mode as well.
5) Get firmware version including build number. Returns 4.5.3.2 with March 2018 TWC. Also returns TWCID of the unit. The old firmware version command returns only 4.5.3 and does not include TWCID.
6) Return (S)TSN plus the TWCID of the unit.
7) Return first 7 characters of VIN number of connected car. If DIP 2 is off (legacy communication mode) or fake car is plugged in, returns all zeros.
8) Return next 7 characters of VIN.
9) Return last characters of VIN.
So the new firmware still doesn't solve the stop/start charge problem or give us battery state. *sigh* But I can update TWCManager to display whether a car is plugged in or not, and to use the VIN number of the plugged car to stop/start the correct car using car API commands.
@CDragon : can you find a trace of that in the firmware ?
Nothing in the firmware checks if GPIO 34 is high or low, so it probably connects to a peripheral that does something when it's high or low. There is only one function in the latest firmware that does anything with GPIO 34: It sets GPIO 34 low as well as setting many other GPIO pins high or low, accesses a number of memory addresses of unknown function, and does something different depending on whether Serial Peripheral Interface A (SPI A) Status Register bit 0x20 is set or not.
What is your firmware version? You can find out using http://<raspberry pi address>/index.php?sendTWCMsg=FB1B&submit=1
If it returns 4.5.3, please get me the extended firmware version using: http://<raspberry pi address>/index.php?sendTWCMsg=FBEC7777<TWCID of slave>&submit=1
Last edited: