Model S motor controller JTAG Hijinks

[collin80]

As promised, I grabbed a Model S drive train controller and found my XDS110 and adapters. As luck would have it, the control board uses standard ARM 14 pin JTAG connectors. Yes, connectors because they used two separate C2000 chips and each has its own JTAG pins.

The two TI chips are:
TMS320F2811 (larger chip that says DSP on it)
TMS320F28035 (fairly small chip)

I was able to power the board and connect to both chips. I used UniFlash on Windows for my attempts. It was able to read and compute CRC for both chips. Both appear to be unlocked on the board I tested. I was able to ask for a dump of the program memory and it seems to have done so.

So, my investigation on the feasibility of extending OpenInverter support *seems* to be going OK so far. Obviously, trouble could still lie ahead and tracing out the connections to both MCUs will probably not be fun. The open question is what OTP bits they might have set (doesn't appear UniFlash will show me this) and whether I can just erase all of flash to zap the password (UniFlash says you can erase section A to reset the password which of course will prevent one from being able to access any of the old firmware).

[Jack Bauer]

So at a guess Elon brain 1 control the motor and brain 2 all the rest. Then they went for the dual core variant on the M3.

[EV_Builder]

As promised, I grabbed a Model S drive train controller and found my XDS110 and adapters. As luck would have it, the control board uses standard ARM 14 pin JTAG connectors. Yes, connectors because they used two separate C2000 chips and each has its own JTAG pins.

The two TI chips are:
TMS320F2811 (larger chip that says DSP on it)
TMS320F28035 (fairly small chip)

I was able to power the board and connect to both chips. I used UniFlash on Windows for my attempts. It was able to read and compute CRC for both chips. Both appear to be unlocked on the board I tested. I was able to ask for a dump of the program memory and it seems to have done so.

So, my investigation on the feasibility of extending OpenInverter support *seems* to be going OK so far. Obviously, trouble could still lie ahead and tracing out the connections to both MCUs will probably not be fun. The open question is what OTP bits they might have set (doesn't appear UniFlash will show me this) and whether I can just erase all of flash to zap the password (UniFlash says you can erase section A to reset the password which of course will prevent one from being able to access any of the old firmware).

LDU or SDU?

[collin80]

As promised, I grabbed a Model S drive train controller and found my XDS110 and adapters. As luck would have it, the control board uses standard ARM 14 pin JTAG connectors. Yes, connectors because they used two separate C2000 chips and each has its own JTAG pins.

The two TI chips are:
TMS320F2811 (larger chip that says DSP on it)
TMS320F28035 (fairly small chip)

I was able to power the board and connect to both chips. I used UniFlash on Windows for my attempts. It was able to read and compute CRC for both chips. Both appear to be unlocked on the board I tested. I was able to ask for a dump of the program memory and it seems to have done so.

So, my investigation on the feasibility of extending OpenInverter support *seems* to be going OK so far. Obviously, trouble could still lie ahead and tracing out the connections to both MCUs will probably not be fun. The open question is what OTP bits they might have set (doesn't appear UniFlash will show me this) and whether I can just erase all of flash to zap the password (UniFlash says you can erase section A to reset the password which of course will prevent one from being able to access any of the old firmware).

LDU or SDU?

The LDU. I have three control boards for LDUs and zero SDUs. I forgot about the ProASIC3 on the board too. Really, the Model S LDU control board is the most over engineered thing ever. I'm pretty sure that people have said that the ASIC is used for hardware based desat detection and to ensure that the gate drive signals are properly offset with deadtime and run in the proper sequence. I assume it also detects if they get stuck and drops them out. Why should that be necessary when the TI chip should be doing all that? That's a good question. I have no idea. That chip costs a decent amount of money too. Just adding the ASIC could have cost them a million or more extra dollars in Model S/X production. If people are right then perhaps the ASIC can just be left alone. But, I haven't taken the time to trace pins to see if that's really what it seems to be for.

[EV_Builder]

The LDU. I have three control boards for LDUs and zero SDUs. I forgot about the ProASIC3 on the board too. Really, the Model S LDU control board is the most over engineered thing ever. I'm pretty sure that people have said that the ASIC is used for hardware based desat detection and to ensure that the gate drive signals are properly offset with deadtime and run in the proper sequence. I assume it also detects if they get stuck and drops them out. Why should that be necessary when the TI chip should be doing all that? That's a good question. I have no idea. That chip costs a decent amount of money too. Just adding the ASIC could have cost them a million or more extra dollars in Model S/X production. If people are right then perhaps the ASIC can just be left alone. But, I haven't taken the time to trace pins to see if that's really what it seems to be for.

Maybe the hardware guys just full-fill a shopping list from the software guys or. The asic is made by the hardware guys and the software by the software teams. and the split in responsibilities / defined interface then results in an asic on there. Timing wise i think nothing beats a asic.
maybe they thought that it would made a difference in the real world.

Now development wise its expensive...