Refer to InstaSPIN_2D00_BLDC-Sensorless-Control.pdf in C:\TI\controlSUITE\development_kits\DRV830x-HC-C2-KIT_v100\BLDC_Int\~Doc , it's talking about config,set up and testing of BLDC_Int only. There is no details of InstaSPIN-BLDC module.
So, How to get source code or document explain of "InstaSPIN-BLDC" module ? Thank you.
Sutthinee,
Sorry, there is a little bit unclear in some of the naming in folders / documentation. InstaSPIN-BLDC = BLDC_Int (Integration technique). This is being cleaned up in the next controlSUITE push.
As for the InstaSPIN-BLDC.lib I agree that it needs a library document explaining the concept. We will be releasing this document probably in December when we release InstaSPIN-BLDC solutions for other kits / MCUs.
The general idea is explained in the User Guide above, at www.ti.com/instaspin-bldc , and the interface to the library supplies some additional clarity
C:\ti\controlSUITE\libs\app_libs\motor_control\libs\InstaSPIN-BLDC\v100\include\
typedef struct
{
int32 Vag; // Internal: Vag input -- contains real Va + VaOffset --> referenced to ground (_iq)
int32 Vbg; // Internal: Vbg input -- contains real Vb + VbOffset --> referenced to ground (_iq)
int32 Vcg; // Internal: Vcg input -- contains real Vc + VcOffset --> referenced to ground (_iq)
int32 Van; // Internal: Va to neutral (_iq)
int32 Vbn; // Internal: Vb to neutral (_iq)
int32 Vcn; // Internal: Vc to neutral (_iq)
int32 VaOffset; // VaOffset (_iq)
int32 VbOffset; // VbOffset (_iq)
int32 VcOffset; // VcOffset (_iq)
int32 Int_Threshold; // Input: Integration threshold where a commutate happens (_iq)
Eintbool Vint_lockout; // Internal: Flyback voltage lockout flag
int32 *Vphase; // Internal: Pointer to the Phase voltage to count (_iq)
int32 V_int; // Output: Integrator (_iq)
Eintbool Comm_Trig; // Output: Commutation trigger impulse
Uint16 State; // Input: Values 0 to 5
} INSTASPIN_BLDC;
Sorry, source code is not given out for this technique.
Dear Chris,
Thank you for your reply. Will wait for document releasing in Dec. If you can expedite, kindly please help.
I have more question related to InstaSPIN_2D00_BLDC-Sensorless-Control.pdf , Page#11 Figure 6 : Graph for Build Level 1.
We are testing my our design board for Level 1, we found that the waveform of BemfA, BemfB, BemfC of my own design board are different from the Figure 6 on Page#11 and the value of BemfA, BemfB, BemfC also differ from Evaluation board. See attached files[BEMFx_value.xls, Graph_mod6_BemfA.jpg].
Differents of my board vs Evaluation board are :=
1) Package: I use 64pin TQFP instead of 80pin LQFP (Evaluation board). Pin compare is attached file[F28035_64PIN_80PIN.xls]
2) Mosfet : I use brand IR p/n IRFB3607PBF instead of Vishay p/n SUM110N06-3m9H.
Could you please advise how to find tuning the waveform to be similar to the waveform of Evaluation board in Fugure 6 ? Which parameter or variable should be adjust to match with my own design board ? Please help to suggest.
Thank you.
6545.BEMFx_value.xls1754.F28035_64PIN_80PIN.xls
Bemf is derived from the voltage sampling. What are the differences between the voltage levels and sampling circuit between the DRV8x kit and your hardware?
Did you run this motor with the DRV8x HW and the GUI? I'd be interested to see what the waveforms look like through the GUI and what Vth level you tuned to.
I think this is one of the first motor solutions where it's actually easier to do all of the development and tuning from the GUI itself.
Attached is also a "lab" that will be in controlSUITE on the next update. You might find it useful to understand some of the GUI features and how to tune the motor.
I cannot prepare waveform through the GUI because my own design board don't have serial.
But by checking/debuging my hardware, we found that the waveform of DRV8301 have something wrong. Please refer to attached file.
The Eval board, input PWM waveform of DRV8301 same as output Gate waveform of DRV8301
But My board, input PWM waveform of DRV8301 differ from output Gate waveform of DRV8301 and always have Fault waveform. *** Refer to attache file.
We built 4 boards, those are the same problem same waveform. So, I think may something wrong on my hardware.
I also attached schematic here. Could you please help to take a look and suggest what is the possible root cause ? Thank you.
3835.BLDC_V1_12Oct10.pdf
8267.DRV_POWER_BASE.pdf
Table 1 on page 16 of the datasheet shows the various fault modes for the device and reporting for each fault. Since this appears to be an "unlatched" fault, we can cross those off the list.
Please step through this table and verify that the voltages are OK and then we can cross those off the list as possible problems.
If you can also tell me what the register settings are that you programmed through SPI, that would help me determine if there is an over-current event. For this, I would also need to have a current probe shot of the current when the fault is occurring.
Ryan Kehr
Motor Drive Application Manager
Dear Ryan,
Let you know first, we are testing both Eval & My own design board without connecting Motor.
By checking OCTW & SPI status register, It's maybe fault mode#2[DVDD undervoltage]. But after check pin DVDD, the voltage is 3.3V which is correct.
Others pin Voltage are following:
GVDD = 11.5 VCP1 = 0.0 VCP2 = 12.0 VDVDD = 3.3 VAVDD = 6.5 VPVDD1= 33 VBST_C = 10.5 VBST_B = 10.5 VBST_A = 10.5 V
All voltage look OK. So, we don't no why Fault is occured and Gate drive output have no correct waveform. Do you have any others suggestion ??
I have attached file(CP2_VCC waveform.doc) which is waveform of VCC & CP2 of Eval board and LA board. Both waveform are the same.
And also attached file(Myboard_Fault_Waveform.jpg) which is Fault waveform since start running code. ***Yellow line is Fault, Pink line is OCTW.- Beginning of code, Fault is High. Then DRV8301 is reset, Fault go low then high. - After that code delay 50ms then RUN motor control, Fault occur immediately like yellow line in waveform.
Regarding the SPI, we used the same code except Eval board used SPIA but My board used SPIB. Codes are attached(Code.rar).
FYI, Eval board used TMS320F28035 package 80pin LQFP but My board used package 64pin TQFP. Pin compare is attached[F28035_64PIN_80PIN.xls]
0535.CP2_VCC waveform.doc
1780.Code.rar
5270.F28035_64PIN_80PIN.xls
I am going to need you to look at GVDD, DVDD, and AVDD with a scope to see if they are collapsing. The decoupling capacitors on those pins are very sensitive to grounding. The capacitors on those 3 pins need to be as close as possible to the device and the GND side of the capacitor needs to be closely connected to the PowerPAD ground. Is the PowerPAD of the DRV8301 (exposed metal tab underneath the IC) properly soldered to the board. This ground pad is the ground for the entire IC and needs to be soldered to the PCB. The decoupling capacitors for the 3 regulators mentioned above need to be routed closely to this GND point.
You will actually notice 2 blue wires on the EVM. These were added as we initially had problems with this same thing on the EVM. The blue wires bring the GND points from th3 3 decoupling capacitors back to the PowerPAD.
Thank a lot for your suggestion. Now, my board can drive & control motor.
But I have one more question, Do we need to re-tuning DRV8301 when we change MOSFET ?
Now,
- Eval board vs Myboard. There are 2 differents(R-shunt, MOSFET). Refer to attached file(Eval_mosfet.jpg & Myboard_mosfet.jpg).
- We are using tuning value which got from Eval to use on my board. We found that compare to Eval board, my board control motor are not much smooth.
-We think, we need to re-tuning when we change MOSFET & R-shunt. We trying to tuning parameter relate to MOSFET. But we are not sure we done it all.
So, Could you please advise what are parameters we need to tuning when we change MOSFET ? Thank you.
Are you using that current sense for a current loop, or just over current protection?
For tuning the commutation with InstaSPIN-BLDC recall that you are looking at the Bemf value on each phase during the off time. But you are using a single threshold value for each. So you should verify
1. balanced feedback circuits. at steady state are you getting near identical Bemf readings on each leg?
2. compare this to the DRV83xx board. What are the magnitude of the Bemf. If they are different, why?
If you are doing a current loop, you should take a similar thought. What is the quality of the current signal you are sampling. Compare it to DRV83xx kit. If it is different, why?
Thank you for your advise.
By our latest testing after changed Mosfet to new IR p/n IRFB3306PBF, the waveform look nice and we can control motor smoothly same as eval board.
Now, we have some more questions would like to verify .
1) What are different between using "Current mode" which done by MCU(TMS320F28035) & "Current limit" which done by DRV8301 ?
2) By my understanding,
"Current mode" will use MCU to detect current at R-shunt to control torque of motor but "Current limit" will use DRV8301 to detect current from RDSon of mosfet for safety & shutdown DRV8301 when some mistake occured. So, we need to use both "Current mode" & "Current limit" together.
Is it correct for my understanding ? Thank you.
Correct.
Current mode is an inner current/torque loop. You will typically want to run this as a cascaded loop inside of a speed loop. Meaning when the speed loop needs to increase/decrease speed it will send a new torque/current reference. You will tune that inner loop depending on how soft or stiff you want the current to increase.
Current limit is a protection for the power electronics. In most cases you are looking at a single current shunt and will take action with the MCU PWMs, however with the DRV83x devices they can monitor the current themselves shut off switching before any damage is done.
Specifically to the the DRV8301, the current protection/limit operates on measured drain-source voltages across the output FETs. You can set the Vds threshold via internal register settings based on the Rdson on the output FETs.
Given variance in the Rdson of the FETs over temperature and process, the current protection in the DRV8301 is meant purely to protect the FETs from short circuits or other fault conditions that would produce a current in the FETs much higher than your chosen operating point. It is not meant for precise current control.
Thank you for your reply.
Base on CLA, HRPWM didn't use in BLDC sensorless. We are thinking to move from TMS320F28035 to lower feature p/n TMS320F28030 for cost saving. But I have one question would like to verify before make decision,
There are different on ADC's conversion time
F28035 4.6MSPS, Conversion Time=216.67ns
F28030 2.0MSPS, Conversion Time=500.00ns
If we move to F28030, do we need to change/re-setting software code related to ADC ? If yes, which parameter ? Please suggest. Thank you.
The ADC clock for this project is set to the chip default which is /4
this is found in
C:\ti\controlSUITE\development_kits\DRV830x-HC-C2-KIT_v101\InstaSPIN_BLDC\BLDC_Int-DevInit_F2803x.c
// LOW SPEED CLOCKS prescale register settings
SysCtrlRegs.LOSPCP.all = 0x0002; // Sysclk / 4 (15 MHz)
This means the ADC is running off of a 60 / 4 = 15 MHz clock.
There are 13 cycles per ADC conversion, so 1/15MHz * 13 = 867ns conversion, which is allowed for F28030
To get 500ns you would need to use a 26 MHz Low speed clock....which means you need to run the CPU at 52 MHz and divide by two.
So no, you don't need to change any code. You should just be able to change your target device to F28030, make sure the memory map is correct, and compile.
Disregard above, completely wrong.
On Piccolo devices the ADC clock comes from the main CPU clock.
You can divide by 2 or 4 (see ADC register settings), but that is not done in the code.
So to change the code to meet the F28030 ADC timing spec you will need to change every instance of the Acquisition Window to the minimum from datasheet table 6-37
AdcRegs.ADCSOC0CTL.bit.ACQPS = 6;
to
AdcRegs.ADCSOC0CTL.bit.ACQPS = 23;
in
f2803xileg_vdc_BLDC.h