openinverter forum

That might have been long but certainly not boring. I do have trouble tracing circuits in stuff like the Tesla boards where the whole thing is covered in plastic. So, seeing someone talk about how they do it is certainly not boring at all! I also am starting to think that I could use more than one DC benchtop supply. Keep up the good fight!

EV_Builder wrote: ↑Wed Nov 11, 2020 11:45 pm Damien wouldn't it be nicer to un-solder the IC and solder a board with connector to the board?
Or maybe just a legged board with connector? long enough that you can solder the pin to the old IC pad?

Did you consider this? or do we need every other pin pulled-up anyway?

@1:39:10.....

Very good work! Perhaps i need to buy me an model 3 engine then too...i always wanted 4WD

Thanks for the support guys:) More updates soon. Glad someone found the easter egg.

Crazy thought here but if people want to help with this project how about making some sense out of the spi captures on the github? Particularly the gate drive and psu.

Jack Bauer wrote: ↑Mon Nov 30, 2020 8:08 am Crazy thought here but if people want to help with this project how about making some sense out of the spi captures on the github? Particularly the gate drive and psu.

I watched the whole video, scouts honor. But, I don't remember the part #'s of those things and don't want to scan the whole video trying to figure out where you said it at. Any chance for a list of part numbers?

EEPROM = 25LC256. Not too worried about this as it probaly contains Elon's recepie for garlic sauce.

Power supply IC = TLF35584

Gate drivers = STGAP1AS

Datasheets attached.

Logic analyser shots and exta info on the repo : https://github.com/damienmaguire/Tesla- ... Drive-Unit

sure would be nice if it wasn't just Colin volunteering .....

Oil pump controller via LIN : LV8907

............

Looks really cool. I want one of these PCB for a keyring.
Non working is just fine for that purpose.

I do not posess the skills to help much here. Sorry.

In case you need someone to test the installation method and maybe help with making the installation guide. As a customers view. There I can give it time to take pictures and video of me messing it up.

Ahhh so are indeed making a drop in Johannes on the m3 mcu footprint. Wifi breakout to the jtag connector?

Thank you for the "long and boring" video, Damien. Fascinating.

I am suitably inspired to try something similar with my Prius Gen 4 inverter board - the design philosophy appears similar and hopefully I can find a (reasonably) easy way to put the on-board micro controllers to sleep. I can then try controlling the IGBT bridges directly...

This should be fun...

Ok, so for the gate driver SPI we have this:

Everything to and from the gate driver chip is an 8 bit value followed by an 8 bit CRC. This makes all transactions 16 bit chunks. Additionally, there must be 6 chips and they're all daisy chained. So, you constantly see 6 duplicate transactions all in a row. That causes all six chips to get their own copy of the transaction. Sometimes they are the same - just sending the same thing 6 times. Sometimes they are NOT the same. Sometimes the low side and high side are configured differently so be careful there.

The first thing it does is send 6 copies of 0xD0 32 (reset status registers).
Wait of about 87us.
0x2A DA (Start Configuration) 6 times
Wait 90us
0x8C A1 (write to register CFG1) 6 times
Wait 18us
0xAA 3D sets CFG1 to AA which means
- enable CRC on all commands
- don't enable VDD undervoltage monitoring
- [BAR]SD pin does reset status registers
- Diag2 pin works as input
- Dead time set to 800ns
- Input deglitch time set to 500ns
Wait 18us
0x9D D6 (write CFG2) six times
wait 31us
0x0D 03 which sets CFG2 to 0x0D which means:
- sense threshold 100mv
- desaturation current trigger at 500uA
- desat voltage threshold at 8 volts
Wait 68us
0x9E DF (write CFG3)
Wait 27us
0x60 38 which basically turns off 2 level turn off.
- It technically sets 2 level turn off to 13V
- but then sets the time to disabled
Wait 27us
0x9F D8 00 0C (Write CFG4 or NOP) Every other chip gets write CFG4 and the other gets NOP (no operation)
34us
0x16 68 00 0C (Set CFG4 to 0x16 on odd chips, NOP on even) This means:
- OVLO disabled (disable voltage monitoring on VH and VL)
- But, oddly enough, set OVLO to be latching
- Negative supply UVLO set to -3V
- Positive supply OVLO set to 12V
Wait 1/4 second
0x00 0C 9F D8 (NOP / Write CFG4) three times. So, now the other chips get CFG4 write
21us
0x00 0C 12 74 (NOP, set CFG4 to 0x12)
- OVLO disabled
- Latched
- Neg supply monitoring disabled.
- Pos supply 12V OVLO
Wait 34us
0x99 CA (CFG5 Write) all six the same
Wait 68uS
0x0A 42 (all six the same) Means:
- 2LTO mode always active (except it seems to have been disabled above)
- Miller clamp feature disabled
- Desat comparator enabled
- SENSE comparator disabled
Wait 24us
0x85 9E (Write DiagCfg1) - Sent to all chips as well
Wait 27us
0x7A BE (Write 0x7A to DiagCfg1) - Enabling something here causes that event to force DIAG1 pin low
- SPI Comm Fault Enabled
- VDD power supply fault enabled
- Undervolt fault enabled
- Overvolt fault enabled
- Desat and sense faults enabled
- ASC feedback DISABLED
- Thermal shutdown enabled
- Thermal warning DISABLED.
Wait 38us
0x86 97 (Write DiagCfg2) - To all chips
Wait 73us
0x00 E0 (write 00 to DiagCfg2) - Disable everything
Wait 27us
0x3A AA (Global reset) - To all chips
Wait 85us

Super exciting? Of course! Well, no, probably not. It's dull but anyone who wants to better understand what they're doing would need the configuration details.

Thank you Colin. That's vital information. I have updated the repo with a pdf of your above post.

Good research. So this gets dumped out once at start up or is it constantly repeated? Could the pauses be replaced by sending NOPs? That would allow to just pre-constract a send buffer and dump it out via DMA.

collin80 wrote:
<snip>

0x86 97 (Write DiagCfg2) - To all chips
Wait 73us
0x00 E0 (write 00 to DiagCfg2) - Disable everything
Wait 27us
0x3A AA (Global reset) - To all chips
Wait 85us

Super exciting? Of course! Well, no, probably not. It's dull but anyone who wants to better understand what they're doing would need the configuration details.

Wow, thorough work! One question - I think that last message, 0x3A, is the StopConfig command, not GlobalReset, isn't it? GlobalReset would be 0xEA. That would make all this a complete configuration of the gate driver chips.

ChazFisher wrote: ↑Wed Dec 02, 2020 9:03 pm Wow, thorough work! One question - I think that last message, 0x3A, is the StopConfig command, not GlobalReset, isn't it? GlobalReset would be 0xEA. That would make all this a complete configuration of the gate driver chips.

You're right. I guess I had a different value pasted into the document and looked that up or something. 0x3A is definitely "stop config"

johu wrote: ↑Wed Dec 02, 2020 1:14 pm Good research. So this gets dumped out once at start up or is it constantly repeated? Could the pauses be replaced by sending NOPs? That would allow to just pre-constract a send buffer and dump it out via DMA.

It happens once on start up then the system begins polling registers at regular intervals but doesn't seem to be doing any configuration past that point. That seems to make sense to me.

The pauses seem somewhat random to me. I don't know if the processor they used just happens to be able to send at that rate or if it's related to some timing tick or what. 25-30us delays seem common with some random larger intervals that I don't know if they're required or not. I believe the documentation says to raise CS for a bit after commands before lowering it again so it's probably a good idea to have the delays in there. But, it's only done once so I don't think there needs to be too much optimization here. Just send, delay, send, delay and then call it a day. The periodic status updates on interval happen much more frequently but still I think actual delays with CS high are required.

Ah it looks like I went to all the trouble making this Isolated JTAG programmer (with optional C2000 processor) for nothing!
Ignore all the bodge wires, I redid the power planes one too many times, dropped a few connections, and couldn't get the correct crystal, and the USB socket stucks. Only joking, I was making this board anyway for one of my projects, it's actually the TMS320F28035 the MCU used in the Model S.
Still want to make a version with the F28379D, or the '77D, but that's going to be a while.

If Elon's getting blasted with hotair anyway, think I could get him in the mail in an antistatic bag ?
Still want to have a go at reprogramming him to take funny cat photos or something.

Thanks for the support folks. @station240 not wasted at all. I have more than one solution brewing at the minute:) Regarding a '77D board check this out :
https://github.com/damienmaguire/TMS320F28377S-

Anyone looking at the power supply ic spi data?

Jack Bauer wrote: ↑Thu Dec 10, 2020 8:06 am Anyone looking at the power supply ic spi data?

Many hands make light word, an extra set of hands makes... lighter work?

The data SUUUUUUUCKS to try to decode. But, I'm doing it. And, Infineon is hereby invited by me to sit on a running chainsaw and attempt a vigorous coupling.

Here is where I was able to get today:

2.4MHz SPI

Unlock code: 1:0xAB; 2:0xEF; 3:0x56; 4:0x12
Lock code: 1: 0xDF; 2:0x34; 3:0xBE; 4:0xCA

You must unlock to change/read protected registers but that data only takes effect when you re-lock the register.

Transactions are 16 bit.
15th bit = CMD, Read = 0, write = 1
14-9 = Address for read/write (MOSI) Nothing for MISO (all zeros)
8-1 = 8 data bits for writing / all zeros on MOSI when reading / 8 read bits from MISO when reading
0 = Parity bit - set so that # of 1's is even across all 16 bits

For reads and writes we send the address to read/write. The reply from the chip has these as status flags that are always zero.

0x8756 = 1 000011 10101011 0 (Write, PROTCFG, 0xAB - First unlock byte)
0x87DE = 1 000011 11101111 0 (Write, PROTCFG, 0xEF - Second unlock byte)
0x86AD = 1 000011 01010110 1 (Write, PROTCFG, 0x56 - Third unlock byte, parity)
0x8625 = 1 000011 00010010 1 (Write, PROTCFG, 0x12 - Last unlock byte, parity)

Sent 0x0C00 = 0b0 000110 00000000 0 = (Read, WDCFG0)
Received 0x80C8 = 1 000000 01100100 0 (Replying, 0x64 - watchdog error threshold = 6, window watchdog disabled, functional watchdog enabled, external WDI input as WWD trigger, watchdog cycle time = 0.1ms)

Send 0x0E01 = 0 000111 00000000 1 = (Read, WDCFG1)
Received 0x81ED = 1 000000 11110110 1 = (Reply, 0xF6 - Top three not used, watchdog enabled while sleep, functional watchdog error of 6 causes reset)

0x87BE = 1 000011 11011111 0 (Write, PROTCFG, 0xDF - First lock byte)
0x8668 = 1 000011 00110100 0 (Write, PROTCFG, 0x34 - Second lock byte)
0x877D = 1 000011 10111110 1 (Write, PROTCFG, 0xBE - Third lock byte, parity)
0x8795 = 1 000011 11001010 1 (Write, PROTCFG, 0xCA - Fourth lock byte, parity)

So, this first set of transactions unlocks the protected registers, reads
two of them (watchdog config), then locks the registers again.

I wish I could have gotten farther but that should at least get people started. That should explain how to look at the data bytes in Saleae Logic and figure out what they mean. Since I decoded the unlock/lock sequences you can just ignore those while decoding / skip over them as they'll be that same thing all the time. The juicy goodness is the operations in between.

This was the beginning of the cold start log BTW. That's where decoding should start - from the beginning.

I did a little more. Here's the continuation. Well, all my notes so far. YMMV about all this. This goes all the way to the end of the cold start file but a lot of it is yet not decoded.

<unlock>
0x8E3C = 1 000111 00011110 0 (Write, WDCFG1, 0x1E - Request WD function in sleep, WD error threshold 15)
0x8DDE = 1 000110 11101111 0 (Write, WDCFG0, 0xEF - Window WD threshold 15, Window WD enable, Functional WD enable, WWD trigged by SPI write to WWDSCMD, 1ms tick period)
0x8A01 = 1 000101 00000000 1 (Write, SYSPCFG1, 0x00 - No delay in state transition, err pin monitoring off in sleep, err pin monitoring disabled fully, err pin monitor recovery disabled, err pin monitor recovery time 1ms)
0x9009 = 1 001000 00000100 1 (Write, FWDCFG, 0x04 - functional watchdog heartbeat timer period 250 cycles)
0x9201 = 1 001001 00000000 1 (Write, WWDCFG0, 0x00 - window watchdog closed window time 50 cycles)
0x9402 = 1 001010 00000001 0 (Write, WWDCFG1, 0x01 - window watchdog open window time 100 WD cycles)
<lock>

Send 0x2E00 = 0 010111 00000000 0 (Read WWDSCMD)
Receive 0x8001 = 1 000000 00000000 1 (Reply 0x00 - Trigger status = 0)

0xAE02 = 1 010111 00000001 0 (Write WWDSCMD, 0x01 - Write 1 to TRIG - Supposed to write inverse of Trigger status we just read)

Send 0x5401 = 0 101010 00000000 1 (Read FWDSTATO)
Receive 0x8061 = 1 000000 00110000 1 (reply 0x30 - FWD response message is wrong, response counter = 3, question = 0 - All are defaults upon reset)

0xB1FF = 1 000000 11111111 1 (Write DEVCFG0, 0xFF - Wake timer enabled in sleep/standby 10ms, 1600us transition delay to sleep)

0xB01F = 1 011000 00001111 1 (Write FWDRSP, 0x0F - Write functional watchdog response here)

0xB1E1 = 1 011000 11110000 1 (Write FWDRSP, 0xF0 - Write second response. No idea what this means)

0xB200 = 1 011001 00000000 0 (Write FWDRSPSYNC, 0x00 - Write last FWD heartbeat sync response here to restart heartbeat)

0xABD5 = 1 010101 11101010 1 (Write DEVCTRL, 0xEA - Tracker QT2 enabled, tracker QT1 enabled, QC0 enabled, QVR enabled, Go to NORMAL mode)

0xAC2B = 1 010110 00010101 1 (Write DEVCTRLN, 0x15 - Inverted bit pattern from above)

Send 0x2E00
Receive 0x8103

0xAE01
0x5401

Send 0x3801
Receive 0x8010

Send 0x4001
Receive 0x8001

Send 0x4200
Receive 0x8001

Send 0x4400
Receive 0x8002

Send 0x4601
Receive 0x8001

0xC000
0xC201
0xC402
0xC600
0xB811

Send 0x3801
Receive 0x8002

Send 0x3A00
Receive 0x8004

0xBA04
0xB803

Send 0x3801
Receive 0x8001

Send 0x2E00
Receive 0x8001

0xAE02
0xB002
0xB1E2
0xB01C
0xB3FD

Send 0x2E00
Receive 0x8103

0xAE01

Send 0x5401
Receive 0x80E5

Send 0x2E00
Receive 0x8001

0xAE02

0xB1D2
0xB032
0xB1CC
0xB22D

Send 0x2E00
Receive 0x8103

0xAE01

Send 0x5401
Receive 0x80EA

Thank you again Colin. Excellent work. I'm more than a little angry that on a forum of over 1100 members no one else could be bothered to even make an attempt.

Hi guys, I have some rusty c/c++ and system engineering skills and I am looking for the right flight path to join you in your EV adventures. I will have a look at those functional requirement specifications mentioned elsewhere. Meanwhile I had to make a first post somewhere so this one is for Damien, keep faith mate, you all are doing great. JW, Amsterdam, P3XL, E31/E32.