The meter is a Fluke, not precisely cheap stuff. I removed the fuses before testing them. I also tried to replace the 10A and the 40A fuses with other 10A and 40A fuses that were the same. I got exactly the same behavior. The problem lies somewhere else. Maybe factory mode would help here...
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
I will... Eventually. Now I think it's too much hassle, a few things can go wrong and I don't have the time to make mistakes... When everything is calm, I'll be able to afford rooting (and replacing the eMMC).
I have no idea if they are compatible, but you can always check the parts catalog
epc.tesla.com
and see the latest revision available for your car.
I now have a t-can pro and full toolbox access. I'm happy to loan either out for a small fee.
Tcan works well for mcu2 hardware if it does what you need...it's a bit limited but does do some basic crash data resets and trouble code reading. Toolbox is reserved for mcu1 cars unless you have a way (or know a person) to root mcu2 but I haven't found a source for mcu2 root yet.
Tcan works well for mcu2 hardware if it does what you need...it's a bit limited but does do some basic crash data resets and trouble code reading. Toolbox is reserved for mcu1 cars unless you have a way (or know a person) to root mcu2 but I haven't found a source for mcu2 root yet.
Hello salvage Tesla people,
@rooter -- thank you for your open-sourced work! I'd be happy to contribute to your wiki once I gain more knowledge.
I don't have a Tesla on my hands but I've got a LDU that I want to control over CAN, and later I want to mess with a small RDU.
However it seems like there are lots of different firmware versions, some of which have different communication protocols or listen to different messages on the bus.
So I want to deploy firmware to my DU using another Tesla (model S) and the firmware-redeploy over Telnet. That way I can just log CAN from that Tesla and be sure the protocols match.
I'm not sure when a redeploy works. I read through this thread Manual firmware update (for new charge port) -- does a redeploy work only when the car is on latest firmware, or can it be done with any vehicle (salvage possibly?)
I was thinking of running a redeploy in a car and just recording the CAN3 (powertrain) traffic, then playing the record back at my LDU.
Also if a record and playback doesn't work I could theoretically disconnect the DU in the car and hook up the external one, then redeploy again.
Has anyone tried something like this? Any tips or tricks?
Alternatively, does anyone have CAN3 logs from an S?
(Also I hope this is a good place to ask -- I'm new here[but not new to EVs] and there seems to be a LOT of knowledge in this thread).
Thanks!
-Isaac
@rooter -- thank you for your open-sourced work! I'd be happy to contribute to your wiki once I gain more knowledge.
I don't have a Tesla on my hands but I've got a LDU that I want to control over CAN, and later I want to mess with a small RDU.
However it seems like there are lots of different firmware versions, some of which have different communication protocols or listen to different messages on the bus.
So I want to deploy firmware to my DU using another Tesla (model S) and the firmware-redeploy over Telnet. That way I can just log CAN from that Tesla and be sure the protocols match.
I'm not sure when a redeploy works. I read through this thread Manual firmware update (for new charge port) -- does a redeploy work only when the car is on latest firmware, or can it be done with any vehicle (salvage possibly?)
I was thinking of running a redeploy in a car and just recording the CAN3 (powertrain) traffic, then playing the record back at my LDU.
Also if a record and playback doesn't work I could theoretically disconnect the DU in the car and hook up the external one, then redeploy again.
Has anyone tried something like this? Any tips or tricks?
Alternatively, does anyone have CAN3 logs from an S?
(Also I hope this is a good place to ask -- I'm new here[but not new to EVs] and there seems to be a LOT of knowledge in this thread).
Thanks!
-Isaac
I have to say that I find MUCH more comfortable to rent a T-Can to reset TAS crash data than sending the module out. It's also cheaper, giving the pricing of @eccl1213, and you can make sure the data was reset properly. If you have to reset the SRS, things become more complicated: depending on your Tesla model, you might need to extract the SRS module and prepare your own harness. But for other models it works straight from the CAN bus. So this is something I would consider if I were to rebuild another Tesla.
I finally properly calibrated the AP2 radar. If someone needs help, I can offer some advice.
Thank you to @Happy Kappy and @rooter for their advice.
Thank you to @Happy Kappy and @rooter for their advice.
What about using a JTAG box and getting in that way by access it directly, once image is dumped you can surely find an entry point to break in.
SInce its an intel atom you can use a sofware development emulator system and so once you get the cpu socketed you would have control of the entire system and excellent reporting. Not sure how much an atom dev system would be to buy used but it's hardly the latest tech...
Is there a jtag interface on MCU2? I have a 2019 MCU 2 with ap3 and all that... just bought, so as long as they follow thru and ship I have a place to stand. Can anyone point me to board and tech info on MCU 2? I would think that Tesla Engingeering just started with a stock Intel Atom board pwb layout and went from there. Expensive to engineer a board from the ground up. Don't think its been done in decades.
As far as rooting, if I can read the bootloader and then reverse assemble it, it can be patched to allow a boot to a usb device. If the bootloader is write protected with a fuse link rom then I'd use the jtag and/or an ICE to dump the startup code and compare it to a stock kernel and look for a low effort spot to patch it.
I used to do high volume motherboard repair in the 1990's and we used a microprocessor development system with a pod that fit in the CPU socket and lots and lots of logic state cards. Repair diagnosis was simple. Run a boot on a good board. Run a boot on a bad board. use the software to compare and see where an address or data bit was stuck and have the rework gal replace the part...
Alternatively I would speculate Tesla uses a standard bios rom. SO, one can read the bios with a jtag, compare and determine which exact version is used, then determine what to patch to get the MCU to boot with the logo off and bios entry enabled, thereby gaining the ability to boot to a flash drive in a usb port. Might have IMPI disabled or not implemented Possible they are using a hard rom for bios and so I will see once my MCU 2 arrives.
Yes, you can. However, you might end up losing supercharging if the vehicle was salvaged. I have to say that they are slow to check, and that even if you don't transfer ownership, they will eventually check your car anyway.
Try VINCheck, and if for some reason the vehicle is still clean there, I think you're good (at least for a while).
