lewurm
Pictures of the Tesla Model 3 MCU board, SD card, HRL and flashing LEDs
Shortly after I've posted #1 I had to travel to the United States for business. Coincidentally I stumbled over a MCU+AP unit on eBay salvaged from a crashed Model 3. Located somewhere on the east coast; shipping to Europe was too expensive, but luckily I had this business trip lined up!
Pics or it didn't happen
Around VIN 51xxx. Upper ports belong to APU (autopilot unit), bottom ports belong to MCU (media control unit).
Left belongs to MCU, right side to APU. The upper two ports are bridged.
Whole package (not my lab that you see in the background unfortunately):
As I found out latter by comparing some pics from the unit of my actual car (VIN 196xxx) it looks like it already has a different hardware revision:
J32 and the white plug above it do not exist on the salvaged MCU. Maybe it's a difference regarding region (EU).
Back to the salvaged MCU, that's how it looks like when you open it up.
... except that I removed already this (WiFi/Bluetooth? EDIT: It's the LTE chip. The datasheet for LE940B6 clearly states that. Thanks @rkantos ):
And when you flip it:
Here is the Intel SoC:
And finally, I uploaded several close-ups of the MCU for detailed studies:
- front: https://imgur.com/a/I6FtxPq There is some duplication as I tried different settings on the camera.
- back: https://imgur.com/a/NPpcdeK
I'll do the same for the APU another day.
As you might have noticed, there is a SD card. Let's dig into it.
Exploring the content of the SD card
I was hoping to find something similar to this: https://youtu.be/Kv_y7J9ROxk?t=558
Unfortunately it looks a bit different:
$ tree m3-mcu-sdcard/
/tmp/m3-mcu-sdcard
├── 0023
├── 002A
├── 002E
├── BOOTED.IMG
├── CBREAKER.MAP
├── HRL
│ ├── 5BD3E9B4.HRL
│ ├── 5BD3E9D2.HRL
│ ├── 5BD3EA3D.HRL
│ ├── 5BD3EA4E.HRL
│ ├── 5BD3EA59.HRL
[.......]
│ ├── CUR.HRL
├── LOG
│ ├── 0.LOG
│ ├── 1.LOG
│ └── LOGINFO.TXT
├── MAP.TSV
├── MODINFO.LOG
├── UDSDEBUG.LOG
└── UPDT
Those HRL files look interesting, there are around 50 in this folder. The files are around 600K-1000K big, so those could be images, right? Well, file and binwalk detected nothing like a picture. Bummer.
Then I was wondering what those filenames could mean, they kinda look sequential. Also it looks like a hex number. Hmm:
$ date -r `printf "%d" 0x5BD3E9B4`
Sat Oct 27 06:29:40 CEST 2018
Interesting.
I looked a bit at its hexdump, but except for the VIN (which matches with the label on the MCU) and some unix time stamps I didn't find much. Searching for "HRL file format" or "HRL Tesla" doesn't give any useful results. Seems like on one hasn't touched those yet? I pinged my friends @gilles-duboscq and @sanzinger. They did the following awesome work:
https://github.com/lewurm/toolsa/
In essence it's some sort of log files that contains records. A record looks like this:
----------------------------------------
|| 1 byte | 4 bytes || 11 bytes |
|| sequence | id || payload |
----------------------------------------
An example is the VIN:
class VINRecord(RecordInterpreter):
def to_str(self, rec):
type = ord(rec.rest[0])
if type == 0x11:
return "Model: " + rec.rest[1:]
elif type == 0x12:
return "Serial: " + rec.rest[1:]
elif type == 0x10:
assert rec.rest[1:5] == '\0\0\0\0'
return "Manufacturer: " + rec.rest[5:]
else:
raise RuntimeError("unexpected VIN record type: {:02x} '{}'".format(type, rec.rest[1:]))
#[...]
_record_interpreters = {
0x1d28: UnixTimeStampRecord(),
0x3c05: VINRecord(),
0xbc05: VINRecord(),
0xb84f: GPSRecord(),
0x3b18: OtherTimeStampRecord(),
0xbb1f: TyrePressureRecord(),
}
VINRecord is signed up for id 0x3c05 and 0xbc05. If it reminds you of CAN bus messages, you are not wrong:
This is from the amazing Model 3 CAN bus sheet put together by @joshwardell et al.: https://docs.google.com/spreadsheets/d/1ijvNE4lU9Xoruvcg5AhUNLKr7xYyHcxa8YSkTxAERUw/edit?usp=sharing
It looks like it wouldn't match the CAN ID here, but the lower 11 bits do:
$ printf "0x%x\n" $(( 0x3c05 & 0x5ff))
0x405
$ printf "0x%x\n" $(( 0x3c05 >> 11))
0x7
The upper part seems to identify something else. Another thing that seems to match is the CAN ID for tire pressure. Snippet of the output by hrl-parser.py:
Record 24 TyrePressureRecord: 28988 / 28989 / 28733 / 28989
assuming it's bar * 10⁴, this looks plausible.
There are many more records to uncover, but it's pretty clear now that we won't find pictures here, so we stopped digging further. PRs are welcome though 🙂
Oh and by the way, if anyone knows what HRL stands for, please let us know. @teslamotors? 😬
Other stuff on the SD card
There are other interesting things on the SD card which we haven't looked into yet:
-
BOOTED.IMGcould be the firmware for the gateway? As far as I know it runs on a PowerPC e200 core, but I couldn't identify anything useful after a quick look. -
0.LOG/1.LOGare300MB/140MBbig. What's in there?
If you want to have a copy of the SD card dump, let me know: lewurm AT gmail DOT com. Not sure if it's okay to put it into the wild...
Let's power up the MCU
Disclaimer: My hardware knowledge is rusty, I'm a lazy software bastard now. Thus my equipment is not the best. I made an educated guess that I'll need to power it up with 12V (you know, it's in a car), and I had some crappy power supply lying around that supposedly should provide 12V.
There is a telling J1 CAN/POWER port on the board. GND was found quickly. J1 has 12 pins, minus two for GND, there are only 10 candidates left. None of them worked. Wut?
Well, I'm smarter now (thanks again to Stefan and Gilles):
- 12V needs to be pretty stable.
- You'll need more than one ampere.
And with that it was not that hard. Since I've spent some time looking around on the board, I identified some more pins on the female J1 plug:
----------------------------------------------------------------
| 1: ? | 3: ? | 5: V12 | 7: ? | 9: CANLo1 | 11: CANHi1 |
| 2: ? | 4: GND | 6: GND | 8: CANLo2 | 10: CANHi2 | 12: ? |
----------------------------------------------------------------
And 🎉: Some LEDs are flashing! More about it next time.
I found this thanks to Github emailing me because of the mention. I would love to help figure things out especially if I can help on the hardware side.
@rkantos Looks like you are right! Googling for "LE940B6" says it's a module supporting "multi-band LTE Cat 6 with 3G/2G fallback". I think I got distracted by the fact that the SIM card is on the MCU board itself, but that doesn't require high bandwidth, so locality doesn't matter. WiFi/Bluetooth is presumably part of the Intel SoC.
The salvaged MCU doesn’t have J32 and the white plug because it’s an old HW2 MCU your is HW2.5
@rkantos Looks like you are right! Googling for "LE940B6" says it's a module supporting "multi-band LTE Cat 6 with 3G/2G fallback". I think I got distracted by the fact that the SIM card is on the MCU board itself, but that doesn't require high bandwidth, so locality doesn't matter. WiFi/Bluetooth is presumably part of the Intel SoC.
To me, who has literally no experience in designing PCBs or anything like that, but who has seen a bunch of teardown of different kind of hardware; All these PCBs look like are something between a tablet and a laptop in terms of design and component placement. Also up until AP HW3, most layouts seem to just be based on typical reference designs (by Nvidia or Intel), as in the past they reminded me closely of a GPU or Intel NUC/UDOO x86 sbc. Now since HW3, the autopilot design is something like I've never seen before, obviously displaying that it is most likely a Tesla design from the start. Now only the MCU looks like a reference design from Intel.
How hard would it be to replace the sim card , have a car from another country would love my own countrys cards instead.
Looking for instructions or at least good pointers :)
How hard would it be to replace the sim card , have a car from another country would love my own countrys cards instead.
Looking for instructions or at least good pointers :)
Have you try it? I would like to make this change also
Thanks
How hard would it be to replace the sim card , have a car from another country would love my own countrys cards instead.
Looking for instructions or at least good pointers :)
How hard would it be to replace the sim card , have a car from another country would love my own countrys cards instead. Looking for instructions or at least good pointers :)
Have you try it? I would like to make this change also
Thanks
Based on the videos I've seen, it shouldn't be too difficult to get to the sim card. If you look at the pictures carefully, you can see that the sim card is on the upper right hand side part of the module (facing inside) on the 3rd picture. As the whole module is designed to be swapped, it isn't too difficult to get to. The only thing that one has to remember really is that the whole thing is liquid cooled, and while it might be possible to get to the sim card without disconnecting the water lines, it is probably best to to disconnect the 12V power completely when taking it apart. I am a bit surprised that there isn't a video of taking the Model 3 apart yet on Youtube; Not that I am aware anyway!
Yes it shouldn't be too dificult to get the sim. I'm just scared by the liquid cooled system and I'm waiting to have a beter view on this by Youtube Thanks
For the sake of completeness: The chip right next to the eMMC (marked as RW229) is the SPI (Boot) flash: https://www.micron.com/products/nor-flash/serial-nor-flash/part-catalog/mt25qu128aba8e12-0aat
Turns out, if you short this one to GND, your MCU will not boot anymore. Like at all. Ever. So, you know, don't do this 🤦♂
For me I am interested to replace the Sim card if any one enable to do it I need to know the steps and if there is video will be great
For the sake of completeness: The chip right next to the eMMC (marked as
RW229) is the SPI (Boot) flash: https://www.micron.com/products/nor-flash/serial-nor-flash/part-catalog/mt25qu128aba8e12-0aatTurns out, if you short this one to GND, your MCU will not boot anymore. Like at all. Ever. So, you know, don't do this man_facepalming
Oh! Which pin did you short exactly?
For the sake of completeness: The chip right next to the eMMC (marked as
RW229) is the SPI (Boot) flash: https://www.micron.com/products/nor-flash/serial-nor-flash/part-catalog/mt25qu128aba8e12-0aat Turns out, if you short this one to GND, your MCU will not boot anymore. Like at all. Ever. So, you know, don't do this man_facepalmingOh! Which pin did you short exactly?
Also wondering about this @0ff
@bequa / @davidh- sorry for my late response. My best guess was that TP45 was related to the SPI chip, I figured that because this pin had the exact pattern of traffic I was expecting for boot SPI (i.e. the timing matched the boot console output).
Once I've shorted this to GND via a resistor, this happened (on that particular boot):
abl-APL: rel.1704
CPU: APL-D0 [4C @ 1600MHz: high SKU], ucode rev.24; warm reset
CSE: FW 3.0.20.1139
CSE: boot dev #2: SPI
PCB #B087: (BMP fab.?, 4x8Gb); BM:0
MRC: [v0.56.22/89.10] S0W OK: 4GB
CSE: send DID UMA @10000000, 34MB
auto-boot ...
image#0 - mmcbootX: eMMC boot: No image [err=2:ACK]
image#0 - mmc1:/iasImage: MMC: 65G, boot 0/0 [5.01 HS400 FW 3.5 4e 5/15]:
GPT FOUND
blockdev_await Transfer time out
*** load err #-4
image#1 - mmc2:/iasImage:
GPT FOUND
*** load err #-5
image#2 - ELK: SB: Enabled
CLI disabled, halt.
This was exactly what I was looking for - the boot loader was forced into booting without SPI and this would enable the CLI (command line interface) if it was enabled. Turns out it was not, so well, I got back to booting without the short. But after that, this is now all that happens:
abl-APL: rel.1704
CPU: APL-D0 [4C @ 1600MHz: high SKU], ucode rev.24; power-on reset
CSE: FW 3.0.20.1139
CSE: boot dev #2: SPI
PCB #B087: (BMP fab.?, 4x8Gb); BM:0
MRC: [v0.56.22/89.10] FB OK(0): 4GB
CSE: send DID .......................\00
Very rarely this happens and then the units reboots ~20 times before going back to the above:
abl-APL: rel.1704
CPU: APL-D0 [4C @ 1600MHz: high SKU], ucode rev.24; warm reset
CSE: FW 3.0.20.1139
CSE: boot dev #2: SPI
PCB #B087: (BMP fab.?, 4x8Gb); BM:0
CSE: ME me error [FWS=0x80002005]
MRC: [v0.56.22/89.10]
For the sake of completeness: The chip right next to the eMMC (marked as
RW229) is the SPI (Boot) flash: https://www.micron.com/products/nor-flash/serial-nor-flash/part-catalog/mt25qu128aba8e12-0aatTurns out, if you short this one to GND, your MCU will not boot anymore. Like at all. Ever. So, you know, don't do this 🤦♂
Is the ABL bootloader stored on the SPI flash?
@bequa / @davidh- sorry for my late response. My best guess was that
TP45was related to the SPI chip, I figured that because this pin had the exact pattern of traffic I was expecting for boot SPI (i.e. the timing matched the boot console output).Once I've shorted this to GND via a resistor, this happened (on that particular boot):
abl-APL: rel.1704 CPU: APL-D0 [4C @ 1600MHz: high SKU], ucode rev.24; warm reset CSE: FW 3.0.20.1139 CSE: boot dev #2: SPI PCB #B087: (BMP fab.?, 4x8Gb); BM:0 MRC: [v0.56.22/89.10] S0W OK: 4GB CSE: send DID UMA @10000000, 34MB auto-boot ... image#0 - mmcbootX: eMMC boot: No image [err=2:ACK] image#0 - mmc1:/iasImage: MMC: 65G, boot 0/0 [5.01 HS400 FW 3.5 4e 5/15]: GPT FOUND blockdev_await Transfer time out *** load err #-4 image#1 - mmc2:/iasImage: GPT FOUND *** load err #-5 image#2 - ELK: SB: Enabled CLI disabled, halt.This was exactly what I was looking for - the boot loader was forced into booting without SPI and this would enable the CLI (command line interface) if it was enabled. Turns out it was not, so well, I got back to booting without the short. But after that, this is now all that happens:
abl-APL: rel.1704 CPU: APL-D0 [4C @ 1600MHz: high SKU], ucode rev.24; power-on reset CSE: FW 3.0.20.1139 CSE: boot dev #2: SPI PCB #B087: (BMP fab.?, 4x8Gb); BM:0 MRC: [v0.56.22/89.10] FB OK(0): 4GB CSE: send DID .......................\00Very rarely this happens and then the units reboots ~20 times before going back to the above:
abl-APL: rel.1704 CPU: APL-D0 [4C @ 1600MHz: high SKU], ucode rev.24; warm reset CSE: FW 3.0.20.1139 CSE: boot dev #2: SPI PCB #B087: (BMP fab.?, 4x8Gb); BM:0 CSE: ME me error [FWS=0x80002005] MRC: [v0.56.22/89.10]
Is the ABL bootloader stored on the SPI flash?
Regarding the SPI flash, according to the documentation at https://www.micron.com/products/nor-flash/serial-nor-flash/part-catalog/mt25qu128aba8e12-0aat
It looks like pin 8 is the reset and hold pin, which would possibly explain why you can't boot anymore @0ff?
Pin 8: Reset and Hold pin
@lewurm Hi, a monitor from Tesla 3 is coming to me soon, but I don't have an MCU to see which SerDes TI on the PCB is used to connect the display. Something like UB949 should be written on the chip, I'm interested in all the characters. Maybe you have the opportunity to photograph him?
@bequa / @davidh- sorry for my late response. My best guess was that
TP45was related to the SPI chip, I figured that because this pin had the exact pattern of traffic I was expecting for boot SPI (i.e. the timing matched the boot console output).Once I've shorted this to GND via a resistor, this happened (on that particular boot):
abl-APL: rel.1704 CPU: APL-D0 [4C @ 1600MHz: high SKU], ucode rev.24; warm reset CSE: FW 3.0.20.1139 CSE: boot dev #2: SPI PCB #B087: (BMP fab.?, 4x8Gb); BM:0 MRC: [v0.56.22/89.10] S0W OK: 4GB CSE: send DID UMA @10000000, 34MB auto-boot ... image#0 - mmcbootX: eMMC boot: No image [err=2:ACK] image#0 - mmc1:/iasImage: MMC: 65G, boot 0/0 [5.01 HS400 FW 3.5 4e 5/15]: GPT FOUND blockdev_await Transfer time out *** load err #-4 image#1 - mmc2:/iasImage: GPT FOUND *** load err #-5 image#2 - ELK: SB: Enabled CLI disabled, halt.This was exactly what I was looking for - the boot loader was forced into booting without SPI and this would enable the CLI (command line interface) if it was enabled. Turns out it was not, so well, I got back to booting without the short. But after that, this is now all that happens:
abl-APL: rel.1704 CPU: APL-D0 [4C @ 1600MHz: high SKU], ucode rev.24; power-on reset CSE: FW 3.0.20.1139 CSE: boot dev #2: SPI PCB #B087: (BMP fab.?, 4x8Gb); BM:0 MRC: [v0.56.22/89.10] FB OK(0): 4GB CSE: send DID .......................\00Very rarely this happens and then the units reboots ~20 times before going back to the above:
abl-APL: rel.1704 CPU: APL-D0 [4C @ 1600MHz: high SKU], ucode rev.24; warm reset CSE: FW 3.0.20.1139 CSE: boot dev #2: SPI PCB #B087: (BMP fab.?, 4x8Gb); BM:0 CSE: ME me error [FWS=0x80002005] MRC: [v0.56.22/89.10]
Do you have a pin out for the SPI? I’m trying to write to an SPI on an MCU2, but would guess it’s slightly similar to the M3 board. Thanks
@rkantos Looks like you are right! Googling for "LE940B6" says it's a module supporting "multi-band LTE Cat 6 with 3G/2G fallback". I think I got distracted by the fact that the SIM card is on the MCU board itself, but that doesn't require high bandwidth, so locality doesn't matter. WiFi/Bluetooth is presumably part of the Intel SoC.
How hard would it be to replace the sim card , have a car from another country would love my own countrys cards instead.
Looking for instructions or at least good pointers :)
have you try it? Do you have any result?
