openinverter forum

So in C2000 laymans terms: if you declare an "int" you end up with "int16_t". If you declare an "int32_t" then you have full 32 bits?

You will find that in the recent master branch a lot of math has been ported to use float. Only the code that runs at 8.8 kHz retains fixed point math. Maybe that is somehow useful.

Folks, can we PLEASE say a big thank you to Dave for this. This is beyond my wildest expectations and VERY far from my ability.

johu wrote: ↑Wed Oct 06, 2021 7:36 am So in C2000 laymans terms: if you declare an "int" you end up with "int16_t". If you declare an "int32_t" then you have full 32 bits?

You will find that in the recent master branch a lot of math has been ported to use float. Only the code that runs at 8.8 kHz retains fixed point math. Maybe that is somehow useful.

If you declare a byte it is 16bits. That's the point. So moving a pointer +1 moves 16bits. Stuff like that if I recall correctly.

@DaveFiddes; that's a very nice amount of work you did there! Good job! I'm still a bit stuck with my mini Remote IO / BMS project , having the schematic finished it's now routeing time. Wish I could join in earlier....

davefiddes wrote: ↑Tue Oct 05, 2021 9:14 pm I've spent a bit of time documenting my current code and getting it pushed to Github: https://github.com/davefiddes/stm32-sine

It comes with a serious health warning. This is not at the point that you can run it on a Tesla Model 3 inverter. If you do so it may damage your hardware permanently.

....

Despite the short list of working stuff I'm about 2 months of full-time work in so far and have been working on it since April. Integer overflow bugs take a lot of effort to find and fix...the TMS320 family of CPUs have 16-bit ints and char is also 16-bit which is quite unusual...

Thank you Dave!

This is allready a lot further than where I could have done anything useful to help with the code part.

The fact that you have put a lot of hours into this, will later seem like it goes so fast after the USB-JTAG was created.

Very good guide on github too, thanks for taking the time to make it.

- Jani

johu wrote: ↑Wed Oct 06, 2021 7:36 am So in C2000 laymans terms: if you declare an "int" you end up with "int16_t". If you declare an "int32_t" then you have full 32 bits?

Yep, that's it. The worst bit is (and I'd forgotten completely) that integer constants in C/C++ are int. This means that you have to stick L on the end of values that might overflow to make sure they are declared long. Urgh.

johu wrote: ↑Wed Oct 06, 2021 7:36 am You will find that in the recent master branch a lot of math has been ported to use float. Only the code that runs at 8.8 kHz retains fixed point math. Maybe that is somehow useful.

I saw you were working on that. This will be very helpful! Just about to set about merging in your latest release.

This is amazing stuff, actually seeing you guys figure this stuff out and see the learning/reprogramming basically as it happens is way more interesting to me than just seeing the finished result, i could only dream of learning to code like this, much prefer the wiring stuff up or making a M3 unit fit in something else than it was designed for.
Huge massive thanks to Dave, Damien and Johannes for all the work gone in so far.
If theres ever anything the rest of us could help with thats not quite as code related always happy to try to help out on the more basic stuff.

davefiddes wrote: ↑Wed Oct 06, 2021 10:11 am

johu wrote: ↑Wed Oct 06, 2021 7:36 am You will find that in the recent master branch a lot of math has been ported to use float. Only the code that runs at 8.8 kHz retains fixed point math. Maybe that is somehow useful.

I saw you were working on that. This will be very helpful! Just about to set about merging in your latest release.

That should be very useful indeed when doing the C2000 port. After all, that's a dual core chip specifically meant for floating point. In reality, while this is probably a tall order, ALL the relevant code should probably use single precision FP even the 8.8kHz stuff. That really seems to be TI's expectation. But, it's an especially tall order as what they really want you to do is use the CLA modules for your tight loops (still with FPU!) and the base processor for high level command and control. Unfortunately, that's about 0% cross platform and would very heavily lock all the code just to the C2000 implementation forever. I'm sure Tesla takes full advantage of the fact that the chip in use is basically quad core (when you factor in that the CLA modules are the same speed as the main CPUs and also can do FPU work). As such, a full implementation would kind of turn the code into a quad threaded beast. Not sure that such a thing is in the cards but it would be interesting to see (some day)

I'm very impressed that so much work has gotten done! Very nice! I'm glad you're working on it. TI's instruction set, memory layout, etc are somewhat deranged. I've tried doing reverse engineering of some C2000 code and it is never pleasant. I wish they hadn't done so many strange things.

One of the advantages we've got is that Johannes' code is targeting a 72MHz ARM Cortex M3. Having lots more horse power makes things easy (ish). I've kept the core control fixed point so I had something known to cross check against. Going to float is certainly a possibility longer term. The most I can see of the dual core is splitting the code so that the core inverter runs on one core and the other does all of the CAN and supervisory monitoring stuff. The key philosophy of openinverter seems to me to be Good Enough(tm) rather than the perfect optimised implementation.

@Damien and @Dave maybe we should register the exact Tesla part number you have.
You do know that we depend on some registry settings in a chip in a highly speed up environment...

@Damien sign me up for a JTAG board. I just might buy a M3 engine to test it...

Will everyone slap me if I bring up the fact that Model S/X drive trains use TI C2000 processors for motor control as well? I mean, if I were a daring man, I might suggest that supporting flashing the Model S drive train directly with OpenInverter firmware might also be pretty cool.

collin80 wrote: ↑Wed Oct 06, 2021 9:43 pm Will everyone slap me if I bring up the fact that Model S/X drive trains use TI C2000 processors for motor control as well? I mean, if I were a daring man, I might suggest that supporting flashing the Model S drive train directly with OpenInverter firmware might also be pretty cool.

Now that's a fun fact. The S/X openinverter board that knows how to run the motor could eventually? be replaced with just flashing the unit then.

But for this topic, could one use some parts of the known openinverter board for Model S/X code inner workings, in the Model 3 C2000 processor code design as a guide how Tesla wants things done in the inverter?

I mean, do they share many other components in the inverter?

collin80 wrote: ↑Wed Oct 06, 2021 9:43 pm Will everyone slap me if I bring up the fact that Model S/X drive trains use TI C2000 processors for motor control as well? I mean, if I were a daring man, I might suggest that supporting flashing the Model S drive train directly with OpenInverter firmware might also be pretty cool.

Call me ignorant but i think that those where code protected.
Only the first versions of the boards had no security and that firmware is swirling around in certain groups.

I might be wrong though.

I think we should wait and see what the future brings.
When we open more and more models of the drive-units we know the answer.
The software is always good to have. Worst-case you need todo the chip job of damien.

In the datasheet it states that you can brick the device if you don't have the password.
Since security isn't the highest prio and reprogramming an must i think that in the newer engines the chip settings are different.

davefiddes wrote: ↑Tue Oct 05, 2021 9:14 pm I've spent a bit of time documenting my current code and getting it pushed to Github: https://github.com/davefiddes/stm32-sine

It comes with a serious health warning. This is not at the point that you can run it on a Tesla Model 3 inverter. If you do so it may damage your hardware permanently.

The README on github explains how to get the code up and building. To summarise what it currently does:

• Port core libopeninv code to work on x86_64 and C2000 with unit tests
• Hardware independent Field Oriented Control / Sine PWM generation (statically virtualised C++ classes using CRTP)(don't ask)
• Port and update existing unit tests and extend to verify FOC PWM generation
• Fix integer overflows affecting C2000 in PWM generation, SineCore and libopeninv

The code will run on a TI LAUNCHXL-F28379D eval board and generate PWM signals running the main FOC control loop with a compiled in shaft angle and velocity. I'm just doing fixed point maths for now to allow easier comparison with the regular STM32 code. Despite the short list of working stuff I'm about 2 months of full-time work in so far and have been working on it since April. Integer overflow bugs take a lot of effort to find and fix...the TMS320 family of CPUs have 16-bit ints and char is also 16-bit which is quite unusual...

My next step from here is to work to port the gate driver and PMIC drivers I wrote back in the spring for STM32 to the C2000. Assuming these can be made to work it should be possible to get high-voltage PWM signals on the Tesla M3 inverter.

We're a very long way from a minimum viable inverter that folks can test or get involved with in any meaningful way. Thought I'd take the time to share where I was at in the interest of openness.

OMG that is simply amazing, well done Dave!

EV_Builder wrote: ↑Thu Oct 07, 2021 8:11 am Call me ignorant but i think that those where code protected.
Only the first versions of the boards had no security and that firmware is swirling around in certain groups.

I might be wrong though.

I think we should wait and see what the future brings.
When we open more and more models of the drive-units we know the answer.
The software is always good to have. Worst-case you need todo the chip job of damien.

In the datasheet it states that you can brick the device if you don't have the password.
Since security isn't the highest prio and reprogramming an must i think that in the newer engines the chip settings are different.

You could be right. It's possible that they somehow password locked JTAG or password locked even being able to erase the chip. I'll put my money where my mouth is (American saying, don't know if it translates fully to other English speaking countries) and try it myself. I have a Model S drive train that I've already bought the OpenInverter retrofit board for. And, I have the dedicated XDS110 TI JTAG adapter. So, once I take the OEM board out I'll give it a try. I might have another OEM board laying around too. One way or another, I'll see if it's possible to flash a Model S control board. The one I have yet to take out is, I believe, one of the newer designs so if it still works there might be some reason to attempt to support the Model S in the new openinverter C2000 codebase. Since Dave has published the source this could be something I could help to do. I suppose this is getting semi-off topic now since I'm referring to a different vehicle, albeit one that uses a similar processor. If I come up with any results I will start a thread for it specifically to keep any more noise out from this one.

That sounds fun. Don't underestimate the amount of work Damien put in to reverse engineering the various signals going in to the MCU though. Bound to be quite a lot of cross-over with the M3. Tesla seem to reuse a lot of ideas from the TI app notes (as you'd expect).

Damien struggled to get the XDS100 going as a JTAG adapter. I don't think it's impossible but I think you need to get the various signals not present on the Tesla JTAG connector but present on the XDS110 pulled up or down as per the TI app notes on JTAG cables. I think this will convince the CPLD on these adapters to tell the FTDI chip that there is actually a target device there. If in doubt try it on a TI eval board or other known quantity. Good luck!

Thank you, Dave, Damien, Joho and anyone else that is helping on this project. I am a builder not a coder and looking forward to a Model 3 solution other than the Ingenext. It's a real pain to send your inverter to them and get it back in a timely matter without the thoughts of it getting lost in the post and making the remnants of the Model 3 motor a paper weight or living room table, boat anchor also comes to mind. Again, thank you guys.

Good news on the hardware front. The Harwin M40-3100545R arrived from Mouser and is a very nice press fit on that silly jtag socket.

Great, how about the connectors, so you plan to include them on the JTAG board kit?

This connector goes on the bottom of the PCB of the JTAG adapter. It just plugs in to the inverter board, hook up a USB cable and away we go. A very neat solution!

Yes, I know how it connects, I just wanted to know if Damiens kit will have all parts or just the PCB with SMT parts on board.

So we don't run into hastily ordering duplicates..

All parts will be supplied in the kit. I should have boards and FTDI chips this week for testing.

looks like we need to change the thread title



see esp 4:38

Good news : jtag boards arrived from jlc. Bad news : there was a slight delay in RS shipping my FT2232 chips. It's all good though as I'll have them in June 2023. Fun though that would be I paid over the odds for 5 pieces from chip one stop. ETA next week.

As soon as you can get online we should try if we can read/ check the configuration registers. We can find use-full stuff in the memory of the device if we can get online while in Elon mode.
Hopefully we have a backup or Dave has the original program still present.

I have an unmodified inverter sitting next to my PC..