openinverter forum

dsp1108 wrote: ↑Mon Oct 18, 2021 3:10 pm
Finished debugging 95 percent.
The loader will try to post on this week.

Awesome!

To Collins point about wiring, it is a bit fiddly, do you think this https://www.adafruit.com/product/2094 would fit?

No it wont fit. The pitch on the M3 jtag header is 1mm. So you need a female 1mm pitch header to match. Good news though! I already sourced one, designed a board around it, tested and then then made the whole thing opensource:)

Jack Bauer wrote: ↑Tue Oct 19, 2021 8:05 am No it wont fit. The pitch on the M3 jtag header is 1mm. So you need a female 1mm pitch header to match. Good news though! I already sourced one, designed a board around it, tested and then then made the whole thing opensource:)

Amazing that i missed that, especially given the amount of time i have spent watching every minute of all your long, boring but wonderful videos.

Just wondering if i could repurpose one of my drawerful of JTAG adapters…

You are an international treasure Damien, please keep it up, as if you needed me to tell you!

Hello.!
I have an incomprehensible problem.
I decided to cheat the discharge circuit.
Removed the key that switches the discharge resistors.

And I have a problem.
Without 12 volts, and a voltage ud greater than 70 volts, I have transistors turned on.
And the engine cannot be rotated.

When I turn off the 12 volt power supply at low revs, my engine stutters !!!

If 12 volts are lost at high speeds, then the power keys may break.

While I understand this problem !!!

Odd. I thought there was a DC-DC converter on the side of the board that was dedicated to creating the gate drive voltages for when 12V failed. The gate drivers should fail safe when the main gate drive DC-DC converter is turned off. In theory none of the drive transistors should be on in this state...

There is an opto (U7) from the backup gate drive DC-DC. Looks like feedback to the MCU on the state of this PSU. I've not figured out which pin it goes to yet but it comes out on TP28. Might be interesting to see what this does in your testing.

Should be possible to test this all in safety on the bench. Measure the gate drive voltage(s), turn off the main gate drive PSU in SW, check for the fault LED and measure the gate drive voltages again.

Great work Dmitri! Спасибо!

Welcome to the forum! Nice to see M3 inverter allready running.

I was thinking of a stragedy:

Important is to catch the first few canbus messages of the M3 drive unit. They contain your actual software revisions. Bootloader and firmware versions.
Then i think it would be good to be able to copy Elon SW to disc and after init of the chip make some screenshot of the configuration registers of the peripherals.

after that flash it with our own software. And after that it would be cool if you can restore back to Elon in case we forgot something or if the project fails somehow .

If we got access to to the firmware of Elon why couldn't we eliminate certain checks like IMMO? Should be well possible....

EV_Builder wrote: ↑Thu Oct 21, 2021 11:10 pm I was thinking of a stragedy:

Important is to catch the first few canbus messages of the M3 drive unit. They contain your actual software revisions. Bootloader and firmware versions.
Then i think it would be good to be able to copy Elon SW to disc and after init of the chip make some screenshot of the configuration registers of the peripherals.

after that flash it with our own software. And after that it would be cool if you can restore back to Elon in case we forgot something or if the project fails somehow .

If we got access to to the firmware of Elon why couldn't we eliminate certain checks like IMMO? Should be well possible....

Yes, the CAN messages have the bootloader and firmware version in them. And, yes, if you had a full image of the OEM software you could disassemble it and remove all the immobilizer checks leaving it otherwise the same. I have seriously considered this myself. In fact, I do have the M3 drive inverter firmware files.

There's just a couple of issues:

1. The firmware is on the MCU itself so you can't scope an external flash chip to get the firmware
2. The chip is not forthcoming with the firmware flashed on it (anyone have a ChipWhisperer?)
3. If you do have the official firmware upgrade files you will find that they are missing 0x2000 addresses at the start of program memory. Since this architecture was made by drunk monkeys and uses 2 bytes per address this means that 0x4000 bytes or 16kb of FLASH is not found in the firmware image that gets flashed to the controller during a firmware upgrade. I have to imagine this means that the 16kb is the bootloader. Alas, I don't have any firmware images where the bootloader itself was upgraded so I'm missing these bytes. And, the bootloader somehow knows where in flash to start executing after it is done so it's kind of tough to figure out where to start disassembling the main firmware at.

dsp1108 wrote: ↑Thu Oct 21, 2021 5:34 pm If 12 volts are lost at high speeds, then the power keys may break.

Yeah, a lot of bad things might happen. The motor is, of course, permanent magnet so if power dies and the motor is rapidly spinning it will become a generator of hundreds of volts. Almost all of the alternatives are bad. If the motor controller just plain shuts off and stops all gate drive then the voltage will freewheel to potentially high voltage. In fact, I'd imagine that the motor can do field weakening so a failure of gate drive could cause excessively high voltage to present at the SiC mosfets. The other alternative is for some gates to still be conducting. That's bad because now unregulated current is flowing, either to bad places or back to the battery. The gates could short the motor which is just a recipe for disaster at high power.

I think the general idea is that 12V should never falter on a permanent magnet controller. It's never a good thing when that happens. I don't know about the failsafe system but usually gate drive drops out when the power does so you'd expect all the gates to go high impedance and turn off. That's not ideal as I said above, but it's probably one of the best outcomes. It's certainly sounding like something odd is happening on the M3 inverter!

My thoughts ....
I have experience designing inverters for pmsm.

First, the self-induction emf is determined at maximum speed (without field weakening).

Power switches are selected with a margin.

For example:
If the self-induction emf at 6000rpm gives 500 volts of the voltage in the Ud link in free wheeling, then the power switches are selected for a voltage of 600 or 750 volts.
With this approach, the loss of 12 volts is not dangerous and the inverter goes into free wheeling.

Tesla, it seems, at maximum speed (18000 rpm) in free wheeling mode, the voltage is higher than the allowable power switches.

And they use field weakening.
And the loss of 12 volts at high speeds is critical.
And they choose the lesser of two evils and came up with a scheme for blocking the rotation of the engine in case of a loss of 12 volts.

These are my thoughts ...
I would be glad to receive comments and ideas from colleagues of electrical engineers and programmers.

Test with original tesla pmsm 3....
Rotate it 1000 rpm without field weakening.
Measure emf at a given speed.
And further, approximate the emf voltage at 18000 rpm.

Now ,I don't have the original pmsm.

Maybe someone knows the emf pmsm of Tesla 3?

In one of my videos I describe the hv derived power supply based on a viper20A IC. It does indeed start waking up around 70vdc on the bus.

On the firmware side all ideas are welcome BUT the idea here is to produce a true open source firmware for the M3 (MY plus other) inverter that can be distributed and worked on publicly just like openinverter.

JTAG adapters now available in the webshop : https://www.evbmw.com/index.php/evbmw-w ... /m3du-jtag

And, the bootloader somehow knows where in flash to start executing after it is done so it's kind of tough to figure out where to start disassembling the main firmware at.

I doubt this would be hard - the first thing the code will be doing is initialising registers,memory etc., and also, chances are it will be at a nice round address, as this would need to be constant for all versions.

mikeselectricstuff wrote: ↑Fri Oct 22, 2021 4:26 pm

And, the bootloader somehow knows where in flash to start executing after it is done so it's kind of tough to figure out where to start disassembling the main firmware at.

I doubt this would be hard - the first thing the code will be doing is initialising registers,memory etc., and also, chances are it will be at a nice round address, as this would need to be constant for all versions.

You are correct, if you know the bytecodes for common init opcodes you could search for those to find functions. Functions generally initialize the stack nearly the first thing so if you can figure out the opcode for that you can search for functions. Additionally, most functions are going to end in an op code for "return". Some architectures use RET, some might use various jump instructions like JL for jump to link register. But, it will be very common to find function epilogues that are consistent. So, yes, it's possible. But still we would need to know whether they jump to a static place in FLASH or whether the bootloader looks for a magic set of bytes or what. I've seen processors where the start function really is found via searching a few ROM locations for the magic bytes. Tesla could be doing that.

It'd sure be cool if anyone could provide me with an image of the bootloader.

ZeroEV has it spinning as well:

Nice:) Missed that. I'm guessing its a proprietary system?

Looks very much like an Ingenext controller box with a ZeroEV sticker on the RHS of their test setup. Sounds very much like they're aiming to put together a turn-key package like they do for other Tesla drive units. Should be a solid solution.

Makes me glad I bought my drive unit when I did. Suspect the breaker prices will start to go up from here.

Yeah true. Would grab one myself but not a free penny these days thanks to house purchase. In related news I did get this nice little donation from a patron.

I saw that video & was wondering - it gives the impression that all they are doing is something with the throttle control, implying that it's the standard Tesla firmware, as it needs to see a Tesla throttle - why would this be the case if it was running alternative firmware?

think someone suggested that this _is_ standard Tesla firmware which has just been “re-paired” with the Ingenext controller so that it works outside of the original car?

Yeah its most likely standard firmware with the immobiliser can message bypassed or set to a known value. Thus the drive unit expects the oem throttle. I'd guess the guys have mapped out the range of the two tesla throttle signals and recreate them with a dac allowing any type of throttle to be used. Neat idea.

My own bias is towards an open firmware that we can all work with and modify.

The just replied to my YT comment - it is Tesla 2021 firmware.

mikeselectricstuff wrote: ↑Sun Oct 24, 2021 6:09 pm The just replied to my YT comment - it is Tesla 2021 firmware.

That settles it then.

They make 'em plug and play.

Here we plug and pray.

mikeselectricstuff wrote: ↑Sun Oct 24, 2021 6:09 pm The just replied to my YT comment - it is Tesla 2021 firmware.

The not great thing about using the drive-train as-is is that Tesla can jam a stick in your spokes any time they'd like. I mean, once it's out of the car the firmware won't change. But, they are free to change the firmware to lock out things like this for future motors out of cars. Naturally, it's probably still possible to downgrade if you have the motor on the bench. But, that would require them to have people send their motors in or only buy the motors from them. I guess that's not so bad from a business perspective as it causes a nice form of market capture for them. But, yeah, it certainly leads down a much more restricted and secret road than what OI is doing.