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

Let the hacking begin... (Model S parts on the bench)

This site may earn commission on affiliate links.
Alright, so power was the reason it didnt turn on. I got ahold of a more powerful supply, and now it boots into "idle" i think. I see lots of activity on the LEDS on the motherboard, but so far i havent been able to get the screen to turn on. Is this because of abovementioned lacking ethernet signal, wakeup signal, or am i just too impatient and it needs a bit more time with power before anything shows on the screen?
 
Assuming you mean the MCU screen, this is a classic symptom of the CID failing to boot.

Have you changed the CID? What is the history here?

Its a used MCU which had Black screen. Owner took it to SC and they managed to boot it. Owner decided to swap because of symptom even if it booted. So i bought it off him to experiment on. Maybe the memory tipped over the last point and failed?

Im planning swap out the memory any ways so its no biggies i dont need the data on it from previous owner, i plan to use it as verification that memory swap was succsessfull before putting it back in car.

Would it boot on power if the memory was intact?
 
Ok, sounds like the CID matches the MCU. ('Curtains match the Drapes'?) You must not have differing software versions in them due to code-signing, else yet another reason why it will not boot.

I'll bet it would boot if you sprayed some liquid cold on the eMMC, as I recommend in my article. I am very suspicious at this point of the eMMC support circuitry being at fault, rather than the memory cells themselves. (yaay Hynix...)

But code-signing also means that you must lay down the exact version of firmware that you are running in the car now, else black screen. (Don't ask me how I know...) Check which of your partitions is active (1 or 2) and build the image as I recommend. Both parts can have the same version as long as it is the current version you are running.

Ya, the most important thing is having your own files. (parts 3 & 4)

PS - It's not 'memory' (RAM), it's flash.
 
Last edited:
Ok, sounds like the CID matches the MCU. ('Curtains match the Drapes'?) You must not have differing software versions in them due to code-signing, else yet another reason why it will not boot.

I'll bet it would boot if you sprayed some liquid cold on the eMMC, as I recommend in my article. I am very suspicious at this point of the eMMC support circuitry being at fault, rather than the memory cells themselves. (yaay Hynix...)

But code-signing also means that you must lay down the exact version of firmware that you are running in the car now, else black screen. (Don't ask me how I know...) Check which of your partitions is active (1 or 2) and build the image as I recommend. Both parts can have the same version as long as it is the current version you are running.

Ya, the most important thing is having your own files. (parts 3 & 4)

PS - It's not 'memory' (RAM), it's flash.

Sorry, i have a bad habit of calling storage space (flash etc.) for memory.

By CID do you mean Instrument cluster, or the daughterboard on the tegra motherboard containing CPU/ flash?
Let's say i put my own cars daughterboard into this donor MCU, will there be code-signing when i dont have the instrument cluster connected to the MCU? Im not sure what version this donor MCU ran before it was detached from the car, but im pretty sure its not the same version i have in my car now (2020.4.1)
 
IC=Instrument Cluster, MCU=Media Control Unit, CID=T3 daughtercard

Yep, that would do it.

When the MCU initializes it starts a boot coprocessor in the Tegra3, which looks to the first address in the Spansion flash (on obverse of the CID) to boot. Early in its boot process (equivalent to its BIOS) the coprocessor turns on code-signing, which thereafter checks that every ECU (Electronic Control Unit) in the car is running the same version of firmware.

If you put your own car's daughtercard into the bench MCU, or the bench MCU's daughtercard into your car, black screen due to firmware version mismatch. (as confirmed by code-signing) Don't ask me how I know...

I have permission from Sid to publish his custom Fusee Gelee hack for Tesla to turn off code-signing, but have no code nor further info.

And rats, I muffed that amusing metaphor; it should have been 'Carpet match the drapes?'. (referring to a woman's hair color)
 
IC=Instrument Cluster, MCU=Media Control Unit, CID=T3 daughtercard

Yep, that would do it.

When the MCU initializes it starts a boot coprocessor in the Tegra3, which looks to the first address in the Spansion flash (on obverse of the CID) to boot. Early in its boot process (equivalent to its BIOS) the coprocessor turns on code-signing, which thereafter checks that every ECU (Electronic Control Unit) in the car is running the same version of firmware.

If you put your own car's daughtercard into the bench MCU, or the bench MCU's daughtercard into your car, black screen due to firmware version mismatch. (as confirmed by code-signing) Don't ask me how I know...

I have permission from Sid to publish his custom Fusee Gelee hack for Tesla to turn off code-signing, but have no code nor further info.

And rats, I muffed that amusing metaphor; it should have been 'Carpet match the drapes?'. (referring to a woman's hair color)

How easy is it to downgrade to before 2019.16?
 
I have heard that the certificates expire at some point. Anyone know how that mechanism works? I imagine if your car was off for six months or a year that the car would refresh them. If you installed the certificates in a Bench MCU2 and it called home could you put it on the shelf for a year and have it refresh itswlf?
Does anybody know the answer to this? How long can the car be completely disconnected before it will be unable to update the certificates?
 
Does anybody know the answer to this? How long can the car be completely disconnected before it will be unable to update the certificates?

you’d have to check the cert expiry dates, but generally they are good for 3-5 years.

But you could be at the start of the certificate life, or the end. No way to know without actually investigating the certificate.
 
Hi Everyone a bit late to the party i guess but trying to get upto speed...

My part on the bench is a 2015 Rear drive unit (85D series).
I was looking for some canbus logs. Has anyone one which he can share?
(or knows a link?).

I need one with the drivetrain data in it.

I'm also looking for a sheet with all the ID's (could only find one for Model 3?!?) .

Hope you guys can help me. The sheet from wk057 is already in my archive :)
 
For folks that are interested, I've started shipping out my CANServer and MicroDisplay boards, as I have the hardware ready but the Arduino-programmable software has a long way to go.
It's an ESP32 that sits on any can bus...and direct plug and play to the chassis bus under the seat... and can not only transmit data to the hud-like displays, but in the future can provide a high bandwidth interface to phone apps, and connect with home nas or Pi servers and offload an entire drive's worth of data.
I am waiting to announce til software is more publicly consumable, but if you are interesting in helping or hacking around I set up a wait list and shipped a few with venmo for costs.
CANserver