BOOSTXL-DRV8323RS: EVM Product Selection and Example Programs

David,

Deciding between the DRV832x and DRV835x is a decision in voltage maximum, they are both capable of using Instaspin. 

The DRV832x has a voltage input max of 60V which easily covers your need, the DRV835x has 100v max Vin. Other than this, they are both latest generation devices with similar features.

Do you need an automotive qualified device?

Instaspin-FOC and Instaspin-Motion are both covered in the user's guide as linked here: http://www.ti.com/lit/ug/spruhj1h/spruhj1h.pdf

The best way to tune a motor is to use Code Composer Studio and Instaspin. The device GUI environments are meant to get a user up and running quickly and simply with little tuning. The nuts and bolts of Instaspin need tuning with the labs which are discussed in the same user's guide above. Inside CCS you can edit all parameters and identify the motor as well as tune it.

Regards,

-Adam

Hi Adam,

Thanks for the info related to product selection.  At this point, we have had some success driving the motor with the GUI, but we need to go beyond that to drive the motor under program control with several variables in the "equation".

For testing purposes, we need to vary the speed of the motor under program control using the BOOSTXL-DRV8353RS.  i.e. equivalent of the GUI to drive the motor, but under program control.  The DRV8353RS-EVM has one PCB with the DRV8353RS gate driver and MOSFETs while the other F28027F "controller" PCB plugs into the main board like a shield. The SPI commands that are documented in the user guides go between the F28027F gate (speed) controller and the DRV8353RS gate driver.  Does the GUI communicate with the F28027F speed controller via the documented SPI commands or some other protocol?  So how do we talk to the F28027F PCB (presumably via the USB since there are no other connectors)?
• Do we need outboard hardware like an Arduino with a program that communicates with the compiled TI module with calls to start, stop and adjust speed, as well as getting readings back from the module for current, RPM, error codes, and any other pertinent information?  If so, what is the protocol and command set?  Is this documented somewhere?
• Should we try to modify the F28027F compiled module to include the above functions, which is effectively putting the GUI driving functions into the speed controller code?  That might not be a good idea since it could slow down the motor control function.

Are there any code examples that we could use to develop such a control program?

Thanks, David Cyr

Hi Adam,

To answer your question about needing an "automotive qualified device", yes we do.  Does that affect the choice of the DRV8353RS or the TMS320F28027F.  The TMS320F28027F MCU is Automotive, AEC-Q100 rated, however, the DRV83x3RS has no Automotive AEC rating according to the data sheet.  Would we be better off with either DRV8343S-Q1EVM or DRV3205EVM for automotive compliance assuming they are functionally equivalent?

Our intent is to use the DRV8353RS and the F28027F MCU with the C2000 generated control code, possibly modified for our purpose as you suggest.  However, given we have not found any documentation describing the communication between the GUI and the F28027F, it would help immensely if there was an example of driving a motor under program control, preferably in C or C++.  After the GUI loads the control program, it makes calls to the F28027F load module to start, set motor speed, etc. and reads data from the F28027F.  If you could direct us to the document or a source code module where this command set and protocol are described, that would be much appreciated.

Thanks,

David Cyr

Hi Adam,

The impression we get from the documentation is that the C2000 firmware COULD be used as is (with user.h customized) if we had the command set used between the GUI and the F82027F MCU.  TI has done 99.99% of the work to get us there, but it appears there is no documentation describing the interface to the F82027F MCU via the USB port.  It will require a tremendous amount of work to needlessly pull apart the C2000 code to either reverse engineer the command set or recreate something that is already defined, debugged and works!  Are you sure this interface isn't defined and documented in a manual or in the source code?

Thank you for your help,

David Cyr

David,

I can ask about this but I know it's unlikely as the EVM was never intended to be easily integrated into an end product. We are not making motor modules. The EVM is designed to be an example that will allow customers to use the DRV and needed surrounding MCU/etc. to evaluate a motor in their system.

Customers who intend to use the same framework in their end application will modify the C2000 code since they would need to do this in their application anyway.

Regards,

-Adam

In the interest of brevity, we did not explain that we would be stripping out the redundant components from the EVM 2-board design and designing our own single board with an application logic controller, the BLDC MCU, the DRVxxx and MOSFETs.  However, the C2000 code has minimal comments and so many source modules that it is difficult to understand what is done where.  The documentation implies that the C2000 code is capable of properly driving a BLDC motor with the appropriate customization (user.h) and correct inputs from the GUI.  If this is not the case, then we have misunderstood the documentation.  If however, the C2000 code can drive a BLDC motor, then all we need is the protocol between the MCU and the GUI, such that we can replace the GUI with our own application logic controller using commands the C2000 code already understands.  Is this command set documented anywhere?

David,

Give me some time to see if I can get this instruction set.

Regards,

-Adam

Hi Adam,

As you suggested, we will likely use the DRV8305-Q1 since it is automotive rated.  It also has the TMS320F28027F-Q1 MCU onboard: http://www.ti.com/tool/DRV8305-Q1EVM so no plug-in MCU module is required. (4.4 V to 45 V, 25 A)   If we can get the DRV8353RS to drive the motor, we'll then design around the DRV8305-Q1.  Hopefully the command set and the interface between the two EVM GUIs and the F28027F will be the same or very similar.

Thanks for initiating this investigation into the instruction set.   David Cyr

David,

I have not been able to get these instructions yet unfortunately.

Regards,

-Adam

David,

Unfortunately I am still waiting for this. I have emailed the team responsible to see if we can provide this.

Regards,

-Adam

Hi Adam,

There has to be documentation on this protocol, somewhere. 

See what STMicroelectronics has provided: 

https://www.st.com/content/ccc/resource/technical/document/user_manual/5e/5e/d2/cb/07/35/45/a6/CD00298474.pdf/files/CD00298474.pdf/jcr:content/translations/en.CD00298474.pdf

Dave

Dave,

The EVM implements a debug probe and JTAG over USB. Do you have a system in mind that could emulate the USB communication or handle the JTAG?

The people I'm discussing this with are failing to see how this would even be implemented.

Would it not be simpler to put a DRV on your board and send it commands yourself?

Regards,

-Adam

Dave,

The document linked looks a lot like the Instaspin documentation which the C2000 team wrote and supports. Maybe they already have something like what you're requesting?

In the end it seems like even the ST Micro solution does Not revolve around using an Arduino or similar to send commands to an ST evaluation board which then spins the motor.

Regards,

-Adam

Hi Adam,

The ST document has calls that initialize the ESC control (start) then commands (current, torque or speed control) to drive the motor.  The TI document has such low level commands that it is virtually impossible to use.  A much higher level of commands is required for us to use the TI firmware.

As far as using an evaluation board, driven by an Arduino, we have no intention of using a TI evaluation board.  Once we can demonstrate that the TI firmware can drive our motor properly (using the evaluation board), then we would start with the evaluation unit schematic and drop out redundant components, and drive the circuit using serial communication to drive the TI motor driver in the same manner the GUI does.  We plan to design a PCB that holds both the customized TI motor driver circuit and our application controller.  Hence the need for the high level command set to drive the TI motor firmware.

Thanks for your help!  Dave

"...put a DRV on your board and send it commands yourself"   That's the idea, BUT what is the high level command set?  The commands in the TI C2000 document are so low level, we will never figure out how to use this low level command set.  For example, there are commands to check the angle of the rotating field (or whatever...) which is not what we had in mind.  The TI firmware needs to provide high level commands like start, run, increase speed, speed ramp up rate, etc.  Dealing with the mathematics is a non-starter!  That's what we thought the TI firmware was supposed to look after...

Dave,

I will be forwarding your post to the C2000 team as they are the only ones who can potentially provide the High level command set you are requesting.

Regards,

-Adam

The InstaSPIN solutions are not meant to be a high-level black box solution that you can simply set some simple commands.

You will need to look for another solution if you aren't comfortable in using the low level software to design your own control system.

The post was put in the wrong thread.

Hi Adam, this was incorrectly posted to the wrong thread, but I did see your response there advising to go to a consulting company...  However, I still maintain that if the TI GUI can drive the motor using the supplied TI firmware, then why can't we do the same from our custom-designed application control software using the same command set as the GUI?  All we need is the protocol/commands used by the TI GUI that talk to the TI firmware.  Why is that so difficult???  If the firmware was better documented, we could figure it out ourselves, but it is far to cryptic.  If your customers have to develop code at the level of the commands below, then there is little benefit in using the TI firmware.  One might as well start from scratch.  At least we would then understand our code!

PREVIOUS POST:

There has to be a misunderstanding here somewhere, as I can't believe it takes someone with 3 PhDs in mathematics, electrical and electronics engineering to develop a motor driver using TI's firmware based on the extremely low level technique to control a BLDC motor.

For example, the InstaSPIN API has commands like this:

CTRL_getIab_in_pu () void CTRL_getIab_in_pu(CTRL_Handle handle,MATH_vec2 *pIab_in_pu); that “Gets the alpha/beta current input vector values from the controller”

Or

CTRL_getVq_out_pu () inline _iq CTRL_getVq_out_pu(CTRL_Handle handle) that “Gets the quadrature voltage output value from the controller”

Or

CTRL_computePhasor () inline void CTRL_computePhasor(const _iq angle_pu,MATH_vec2 *pPhasor) that “Computes a phasor for a given angle”

Why should we have to deal with flux, angles, phasors and vectors, when all we want to do is drive the motor at variable speed within specified constraints, check for errors and restart if it falls over?

Most fixed parameters are specified in the user modules, so if there were an example of motor control then we might be able to adapt that for our motor driver. Preferable would be an example of simple motor control that interacts with the TI motor control firmware at the level of start motor, increase/decrease speed, stop motor, check for errors, etc., then we could reasonably communicate with the TI firmware to control our motor. If we have to reinvent the control logic at the level of the sample commands above, then you are right, we can’t use the TI offerings.

Dave