This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

InstaSPIN High Voltage kit versus TIDM-SERVODRIVE/IDDK/DesignDrive - please clarify the difference

Other Parts Discussed in Thread: DESIGNDRIVE, TIDM-SERVODRIVE, DRV8301, DRV8301-69M-KIT, CONTROLSUITE, LAUNCHXL-F28027, TIDA-00195

Hello, both kits are based on C2000 MCU but InstaSPIN is offered up to F28069 while DesignDrive offered only with the latest  and greatest F28377 MCU.

IT is not including InstaSPIN with DesignDrive/IDDK and I am getting confused with this spread of multiple solutions. Some version of FOC library is provided for IDDK/DesignDrive  to drive motors but not InstaSPIN... I like that IDDK / TIDM-SERVODRIVE includes 3 types of the phase current sensing allowing to compare the results.

Why InstaSPIN  is not included in the latest IDDK/DesignDrive software  ?

What are the differences for the developer?  My project is to drive motor (not a servo) 84v voltage 3 phase high power output BLDC 20kW experimenting with different number of coils/poles and with RPMs/volt... There is no executable program for IDDK similar to InstaSPIN helping to figure out the optimal motor parameters but there is library in DesignDrive and probably examples to play with motor... Will TI release another executable software for DesignDrive/IDDK similar to InstaSPIN?

Please share your thoughts about when and how to prefer one over the other to drive high power 3 phase BLDC  motors with and without sensors.

Thanks in advance


  • Hi Vladimir,

    When C2000 works with customers, we see two different types of customer in the motor control space: 

    1) A customer/company who is finding it difficult to get the most out of their motor (this could be because they're new to DSP/MCU software, it could be that they don't have enough experts in motor control, it could be because the time needed to get a good product designed is longer than they can resource, etc)

    InstaSPIN is largely centered on helping this customer get to market quickly with very high quality control.  We've seen the performance beat many customers' existing systems.

    2) A customer/company who is a veteran at motor control and/or software.  Furthermore, they really want to keep/build all experience and knowledge in-house 

    For this type of customer, we release open-source software solutions to drive motors - mainly to help customers evaluate our device and its peripherals. These examples give a good place to start with our device, but there is an expectation that more work would be needed to build a motor control solution that meets the customer's specifications.  The IDDK/DesignDrive platform is largely focused toward this type of customer.

    TI has plans to continue to support both approaches.  Either model could be valid for your 3-phase BLDC application.

    Hopefully this helps to answer your question.

    Thank you,

  • if you want to use InstaSPIN you should start with an EVM and a lower current/voltage motor to understand the control system. scaling this up to a high current HW is easy in SW. But following a TI design for the layout is important and you should look at the requirements for InstaSPIN in SPRUHJ1
  • THank you Brett, it makes sense now.  I'd prefer the second if only there were good examples of using the DesignDrive library to build BLDC control application with adjustable speed control and using different methods of current sensing with matching reference design or demo controller for our battery volts (eventually expandable by us to higher Amps without limiting predriver standing between MCU and power module).

    Unfortunately I haven't found a good modular hardware demo board from TI for neither DesignDrive nor InstaSPIN.   Both are hardly expandable to our power needs without changing MCU connections and whence software control. 

    All InstaSPIN demos use all-in-one predrivers like DRV8301 which limits voltage to 60v. Software is built to get sensing from and to control this chip.  To build 84v system with high load current requires to drop this chip, which will follow changes in MCU connections and code... and nowhere I can find TI examples of modular power section built around discrete components - like separate gate driver,  controller' feed isolated from half bridge' power bus, separate current sensing and separate library modules to run all the modules separately.

    We already got DRV8301-69M-KIT  as suggested to us but after realizing that we don;t need run 60v limited demo - change in schematic (replacing DRV8301)  may require changes in using library as well, decided not to proceed ... Our power module separate half bridges power module bus should be isolated from controller' bus (no boost pump, any hardware design examples from TI?) but then software changes might be due as outcome ...

    DesignDrive/IDDK demo uses Mitsubishi module which is another example of "high integration" - from shunt sensing to even half bridges fit into the same package. Documentaion is not clear on how to choose battery bus range under 100v and we need more powerful parallel mosfets half bridge modules and current sensing  instead of Mitsubishi module. No reference design examples to fit our needs in, not clear how to change software when Mitsubishi module is gone and current/voltage sensing should reach MCU some other ways...

    I might be wrong on this too but seems that only Infineon  offers all modular demo boards and software not  limiting architecture by max voltage or by predriver' output current ...   I wanted to build our controller on the top of TI's LaunchPad - I tried to find motor controller' reference design from TI for our voltage range and user-expandable phase current  BLDC  for either DesignDrive or for InstaSPIN  - but no success so far...

    Thank you all for help - this forum is unparalleled in industry ....


  • Hi Vladimir,

    About modular demo boards -

    Kits for the C2000 family are largely designed to be for evaluation/experimentation of the device and prove that we are applicable to a specific customer's system.  They're not really intended to be used directly in a customer's end-product.  That being said, a good number of them are decent designs.

    Because of this, we enable some modularity in our designs - especially in the ability to change between C2000 devices.  However, when modularity weakens the ability for us to help a customer evaluate our chip, we stop. 

    For example, we wouldn't make the IPM on TI's IDDK kit modular - doing so could add additional noise in the system and weaken our ability to show the performance of our chip.  It's also the case that one IPM or a set of IGBTs or a set of MOSFETs are not identical - while the system software could manage the complexities of handling extra interface signals, deadband differences, etc - it obscures the goal of evaluation.

    It is feasible to build a cCARD baseboard or a launchpad boosterpack which is an inverter built to meet the specs of your system - however, this would be a task we'd leave to you.  And if you were to build such a baseboard, I might recommend that you go ahead and put the chip on the board and improve your system's performance though ;).


    About the IPM/driver chip -

    Please note that the IPMs (either the DRVxxxx or the Powerex one), make the system somewhat simpler, they are NOT doing everything that you are stating they do.  For example, in both designs leg current sensing is done via shunt resistors - not by the IPM.   The same can be said for the phase voltage. 

    These analog signals then make their way to the C2000 device, the software runs the control loop, and then outputs the PWMs that will go to the FETs.


    About software -

    Whether you're running a high-voltage inverter or a low-voltage inverter, at a high-level the C2000 will do the same type of thing to control it - take in currents and voltages, run FOC, and output PWMs. 

    You should go in expecting to need to make software changes (whether using TI's stuff or another vendors).  For instaSPIN, some of the software is in lib form, but the part that most customers would need to edit is open.  For non-instaSPIN, the code is open.


    About your system -

    It sounds like your system will need to use isolated gate transformers or isolators to drive your inverter - the IDDK can be a reference for this.  On the sensing side, you'll likely need to use LEMs.  Both are feasible changes whether you use InstaSPIN or not. 
    (if you go the non-InstaSPIN route, you can also use the F28379D and utilize sigma-delta modulator/demodulators - in the IDDK system, the sigma-delta interface was more accurate than the LEMs)

    Thank you,

  • Brett , I might indeed overestimate changes to the sw needed if replacing integrated pre-drivers with basic gate drivers to isolate power feed.... If the only change is which pins to read sensors from - I don't care about that (assuming it is easy to find include files where this is defined)...

    Hardware definitely need more changes...

    Ideally I'd like to prototype LaunchPad F28069M with burned in InstaSPIN library with a custom booster pack board made similar to IDDK isolated driving circuitry  but the chip PS21765 should be replaced with basic IGBT gate drivers.  Also LEM sensors outputs connected in IDDK to that same PS chip ( how does it even get to the MCU ? I can;t figure out from schematic).

    Can you point me to the TI's reference designs for this inverter module change?  I understand TI's approach to simplify demo boards with highly integrated pre-drivers but there might be reference designs using just gate drivers connected to TI's MCU PWM pins on one side and driving user's IGBT bridges on another...

    And as I mentioned before - LEM output - could it be connected directly ( OP'ed, scaled and isolated ) to MCU GPIO for reading, why through IPM ?

    Thank you for help


  • Hi Vladimir,

    Two notes:

    1) The LEMs are definitely NOT connected to the IPM chip in the IDDK.  In the IDDK, we are using standalone LEMs to measure the V and W phase currents.

    Are you looking at the following schematic in controlSUITE?

    [M4]-U1 is the IPM and [M5]-N1/[M5]-N2 are the LEMs.  The output of the LEMs go to the C2000's ADC module as "Ifb-V" and "Ifb-W". 
    ([Main board]-H1 is the connector where the F28379D controlCARD plugs in)

    2) We don't have too many designs that utilize IGBTs, but there are a few.  One that comes to mind is the following:

    There is also a TI Design which is an example of more optimized gate driver circuitry.  One example is below:
    (this design was actually made to potentially plug into the HV_1PH_DCAC)

    Thank you,

  • Brett, thanks for clarifications. I was confused by the same names Ifb-W Ifb-V on IPM  (the 1st schematic page)...

    The design you point out HV_1PH_DCAC is not in my controlSuite... I have it updated (my is free version).

    But I've found fully isolated gate drives reference design TIDA-00195 from TI which is close to our needs. It is controlled by Launchpad LAUNCHXL-F28027 (I am sure can be used with F28069M too) .  Few things not clear though -

    1. Introduction doc states that this design for Induction AC motors...  Can't this design work for BLDC too?

    2. why external IGBT bus voltage starts from 400v ? Our battery system will provide 84v now and in later phases up to 108v DC bus... Other reference designs from TI limit DC bus to no more than 60v... quite a " gap" between 60v and 400v ! Am I missing something?

    3. This design seems to include everything needed between MCU and final inverters, except there is no current sensing per phase...  MCU'  FOC software needs current per phase reading to work, yet it is missing.

    I appreciate your help


  • Hi Vladimir,

    1) Yes an IGBT driver is an IGBT driver.  The solution mentioned is to an example use-case.
    2) For the exact details on the IGBT driver reference designs, I'd post to the Motor Drivers forum.  I see some posts there regarding this design.
    3) For the current sensing, I'd again recommend using the IDDK kit as a guide.  Then edit it as necessary for your application.

    Thank you,