Problems with STM32 PMSM FOC SDK

[Dave_PT]

I checked my IAR project. It defines the following globals:
USE_STDPERIPH_DRIVER
STM32F10X_MD
ARM_MATH_CM3

Here is the search path for .c/h files:
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\Libraries\STM32F10x_StdPeriph_Driver\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\interface
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\interface\common
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCApplication\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCApplication\interface
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\UILibrary\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\UILibrary\interface
$PROJ_DIR$\
$PROJ_DIR$\SystemDriveParams

Now that I see, this is described in Chapter 10.3 of the manual, but I'm using the IAR for the first time ...
Where do I declare global variables and define the path of includes?

Here?

[tatus1969]

Your Eclipse project file is not included there, that would be essential. The library extensively uses #define rubbish.

You wanted to say IAR, right?
Please do not ruin my head  .

That's human communication. After you wrote that you cannot export the project to IAR, I thought that we should stick with getting Eclipse/GNU to work. But didn't write it 

[tatus1969]

I checked my IAR project. It defines the following globals:
USE_STDPERIPH_DRIVER
STM32F10X_MD
ARM_MATH_CM3

Here is the search path for .c/h files:
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\Libraries\STM32F10x_StdPeriph_Driver\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\interface
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\interface\common
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCApplication\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCApplication\interface
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\UILibrary\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\UILibrary\interface
$PROJ_DIR$\
$PROJ_DIR$\SystemDriveParams

Now that I see, this is described in Chapter 10.3 of the manual, but I'm using the IAR for the first time ...
Where do I declare global variables and define the path of includes?

Here?

There are readily pre-packaged projects, have a look in Project/EWWARM. You should only need to configure the debugger, and maybe select the correct MCU type after selecting the correct project. The project name suggests that you already had done these steps? The #define config pane that you are looking for here is under "C/C++ Compiler", tab "Preprocessor".

[Dave_PT]

Yes, I had already changed the processor to be the same as I am using.



The preprocessor settings are correct. Just like you said.




On this board ... no clues for it to work, right?
It seems that everything is right, but something prevents it from working ...

[tatus1969]

Yes, I had already changed the processor to be the same as I am using.



The preprocessor settings are correct. Just like you said.




On this board ... no clues for it to work, right?
It seems that everything is right, but something prevents it from working ...

Wouldn't say that. I'm chasing three possibilities:
1) toolchain problem, project setup -> I think as you managed to migrate to IAR using the default projects (I assume you could flash and run the code with it, and get the same result - no PWM, right?) we can cross this out.
2) board compatibility -> I see only the BKIN issue as possible reason why you don't get PWM signals. I remember from all the documentation that there was a side note that, on some STM32F derivates, this feature cannot be disabled in the timer block. Don't remember where that was though. I decided back then to sacrifice one GPIO for that, and tie it to GND. So it is possible that, even though you disabled that feature in the configuration tool, it is still ruining your day. Maybe do a test and desolder that R8 resistor, this way the driver chip could see a HIGH, and PB12 could see a low. Then enable the BKIN feature again, check it is assigned to PB12 and configured HIGH-active.
3) the FOC library has a number of protection mechanisms that cause it to shut down. For example, over/undervoltage. You could easily see via RS232 and the STMC Workbench's remote control, if one of them is alarmed. I didn't ask that yet: I assume that you supply the board with 24V, right?

You could also start debugging the code, and see if one of the protection mechanisms is shutting down the PWM. But as most of the FOC libary is only available as a binary blob, that can be very difficulty. A good starting point could be MCTasks.c --> TSK_SafetyTask(). This function is regularly called from an interrupt service, and checks for problems.

[Dave_PT]

1) toolchain problem, project setup -> I think as you managed to migrate to IAR using the default projects (I assume you could flash and run the code with it, and get the same result - no PWM, right?) we can cross this out.

Exactly.
I've always used the IAR to send code to the MCU. And I already showed you that I can debug.

2) board compatibility -> I see only the BKIN issue as possible reason why you don't get PWM signals. I remember from all the documentation that there was a side note that, on some STM32F derivates, this feature cannot be disabled in the timer block. Don't remember where that was though. I decided back then to sacrifice one GPIO for that, and tie it to GND. So it is possible that, even though you disabled that feature in the configuration tool, it is still ruining your day. Maybe do a test and desolder that R8 resistor, this way the driver chip could see a HIGH, and PB12 could see a low. Then enable the BKIN feature again, check it is assigned to PB12 and configured HIGH-active.

This would be a method of securing this issue ...
Is the polarity of BKIN high?

3) the FOC library has a number of protection mechanisms that cause it to shut down. For example, over/undervoltage. You could easily see via RS232 and the STMC Workbench's remote control, if one of them is alarmed. I didn't ask that yet: I assume that you supply the board with 24V, right?

Yes of course.
I've checked several times, because in the Renesas board I had a problem with the supply voltage of the circuit ...

You could also start debugging the code, and see if one of the protection mechanisms is shutting down the PWM. But as most of the FOC libary is only available as a binary blob, that can be very difficulty. A good starting point could be MCTasks.c --> TSK_SafetyTask(). This function is regularly called from an interrupt service, and checks for problems.

I'll debug and analyze this function better.
In the meantime, it may be that the new EVB arrives and can do more tests.

Thank you. 

[Dave_PT]

You were right.
But it's strange because I measured the voltage and it's correct.

I measured 1.95V at resistor R14 (Vbus ~ 24.3V).

I lowered the voltage to 15V and still have that error.
I've commented this line and I already have PWM in the outputs ....

[Dave_PT]

The new EVB has arrived!

I am doing the first setup and the first tests written in the documents.

[tatus1969]

This would be a method of securing this issue ...
Is the polarity of BKIN high?

It can be configured in the TIM1 peripheral, and "OVERCURR_FEEDBACK_POLARITY" controls it. In the STMC Workbench, Power Stage -> Overcurrent Protection -> Overcurrent feedback signal polarity.

[tatus1969]

You were right.
But it's strange because I measured the voltage and it's correct.

I measured 1.95V at resistor R14 (Vbus ~ 24.3V).

I lowered the voltage to 15V and still have that error.
I've commented this line and I already have PWM in the outputs ....

You can also uncheck the "Bus Voltage Sensing" in STMC Workbench "Power Stage" section.
The alarm is configured by the following definitions:
VBUS_PARTITIONING_FACTOR
OV_VOLTAGE_THRESHOLD_V
UD_VOLTAGE_THRESHOLD_V

Something must be wrong with one of these. I cannot find a mistake in your "drive_alte.stmcx", maybe a bug in the STMC Workbench?

You can look up all the relations in the STMC Workbench -> Help -> Content menu, then Supported Classes Parameters -> Single Motor.

[tatus1969]

another quick question: are you sure that you compile in the same SystemDriveParams\* files that were generated by the STMC Workbench? Simple test is to have the Workbench repeat generating these files, and pressing Make in the toolchain. That has to trigger rebuilding some of the files. I really cannot find a single error in any of these files...

Code: [Select]

#define OV_VOLTAGE_THRESHOLD_V          32 /*!< Over-voltage
                                                         threshold */
#define UD_VOLTAGE_THRESHOLD_V          18 /*!< Under-voltage
                                                          threshold */
#define VBUS_PARTITIONING_FACTOR      0.0833 /*!< It expresses how
                                                       much the Vbus is attenuated 
                                                       before being converted into
                                                       digital value */
#define MCU_SUPPLY_VOLTAGE    3.30
Have you stepped into TSK_SafetyTask_PWMOFF ? Are you sure that it is the voltage monitor that is tripping?

[Dave_PT]

The files generated by the configurator are those compiled. I see this when I change values and the files in the compiler change as well.

I'll forget for now the EVB STEVAL-IHM040V1.

It is best to start over, but using EVB P-NUCLEO-IHM001 (as it should have done from the beginning, my fault).

While I'm doing some calibration ... I leave some questions.

How can I configure another serial port?
Do I have to do all the setup in the registers?
Or can I use the serial port using the SDK?

I know it may sound silly questions ... but for now it's causing me some confusion ...

[tatus1969]

The files generated by the configurator are those compiled. I see this when I change values and the files in the compiler change as well.

I'll forget for now the EVB STEVAL-IHM040V1.

It is best to start over, but using EVB P-NUCLEO-IHM001 (as it should have done from the beginning, my fault).

While I'm doing some calibration ... I leave some questions.

How can I configure another serial port?
Do I have to do all the setup in the registers?
Or can I use the serial port using the SDK?

I know it may sound silly questions ... but for now it's causing me some confusion ...

The problem with over/undervoltage monitor will probably not disappear, because 2V @ ADC matches well with 24V bus voltage. Better keep that feature disabled and leave it for later.

The STMWB has templates for NUCLEO-IHM07 and -08, you can check if these have identical microcontroller pinout. Then you'd only have to copy the motor parameters. There is a top row button that gives you an overview of the pin assignments, it looks like a chip.

Re the serial port: Do you mean on the Windows machine, or do you mean the microcontroller pin assignment? The latter is in STMCWB under Control Stage -> User Interface  (enable it there), and Control Stage -> Digital I/O. For the Windows machine, click on the symbol that looks like an analog gauge.

p.s. overvoltage protection can be very important, if your system can go into regenerative operation, and your bus voltage has the ability to charge up. For example, if the controller abruptly decelerates the motor and the mass that is attached to its shaft, then you'll have a considerable amount of energy being fed back into the DC bus, charging the bus capacitor. If nothing is keeping the voltage down, you can easily run into overvoltage, and boom. If your system supply will be a simple DC/DC converter, that can easily happen. If your supply is a battery that is directly connected to the bus, then that will suck in the excessive energy. Unless you have a fuse that can blow (which is what happened to me...).

[Dave_PT]

The STMWB has templates for NUCLEO-IHM07 and -08, you can check if these have identical microcontroller pinout. Then you'd only have to copy the motor parameters. There is a top row button that gives you an overview of the pin assignments, it looks like a chip.

In the version I have already has a template for P-NUCLEO-IHM001.

Re the serial port: Do you mean on the Windows machine, or do you mean the microcontroller pin assignment? The latter is in STMCWB under Control Stage -> User Interface  (enable it there), and Control Stage -> Digital I/O. For the Windows machine, click on the symbol that looks like an analog gauge.

In the MCU.
Because in the future the goal is to send speeds via serial port.

p.s. overvoltage protection can be very important, if your system can go into regenerative operation, and your bus voltage has the ability to charge up. For example, if the controller abruptly decelerates the motor and the mass that is attached to its shaft, then you'll have a considerable amount of energy being fed back into the DC bus, charging the bus capacitor. If nothing is keeping the voltage down, you can easily run into overvoltage, and boom. If your system supply will be a simple DC/DC converter, that can easily happen. If your supply is a battery that is directly connected to the bus, then that will suck in the excessive energy. Unless you have a fuse that can blow (which is what happened to me...).

In my situation the power comes from a battery. Over voltage should not be a big problem. But I must be aware of this problem.


So far everything is going well  .
I already switched to my motor and it works fine. I will now try to enable the encoder control.

PS: before that I have to solve another problem. Sometimes I have overcurrent errors. I have to see how I can change the threshold (I've already changed "Over Current Protection" but it's still the same effect).

[tatus1969]

Because in the future the goal is to send speeds via serial port.

You can either tell STMCWB to configure one of the serial ports for STMCWB remote control, or disable that feature which frees it for you to.

So far everything is going well  .
I already switched to my motor and it works fine. I will now try to enable the encoder control.

Great!

PS: before that I have to solve another problem. Sometimes I have overcurrent errors. I have to see how I can change the threshold (I've already changed "Over Current Protection" but it's still the same effect).

I strongly recommend to check current control loop stability first, to do that route Id and Iq to the two DAC outputs, and attach a scope. What I do then is to pulse the Iq setpoint (that part which is not contributing to torque), and watch the result on the scope. If your overcurrent circuit triggers, it can be an indication of current loop instability. I use this code to generate the setpoint pulse:

Code: [Select]

static int i=0;
i++;
FOCVars[M1].Iqdref.qI_Component1 = 0;
if( (i%300) < 150 )
{
FOCVars[M1].Iqdref.qI_Component2 = (int16_t)( 1.0f * (65536.0f * (float)(AMPLIFICATION_GAIN / MCU_SUPPLY_VOLTAGE) ) );
}
else
{
FOCVars[M1].Iqdref.qI_Component2 = 0;
}
I run this in a cyclic interrupt, in my case at 2kHz. And I make sure that no velocity control is in place, that would interfere with it.

Another useful hack is disabling the angle measurement, this way you can apply motor current without having it spin up. Easier than blocking the motor mechanically for some tests. This is part of MCTasks.c:

Code: [Select]

uint16_t FOC_CurrController(uint8_t bMotor)
{
  Curr_Components Iab, Ialphabeta, Iqd;
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  Curr_Components IqdHF = {0,0};
#endif
  Volt_Components Valphabeta, Vqd;
  int16_t hElAngledpp;
  uint16_t hCodeError;
 
  hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC[bMotor]));
  static int16_t k=0; k+=1; hElAngledpp=k;  <<<<<<<<<< inserted, very slow motor rotation
 
  PWMC_GetPhaseCurrents(oCurrSensor[bMotor], &Iab);
 ...


PS: before that I have to solve another problem. Sometimes I have overcurrent errors. I have to see how I can change the threshold (I've already changed "Over Current Protection" but it's still the same effect).

There is only one mechanism reporting overcurrent, and that is the BKIN feature. An overcurrent can only be reported by the hardware comparator(s). There is no need for a software based overcurrent monitor, because the FOC algorithm *controls* the current (unless there is loop instability).

[Dave_PT]

There is only one mechanism reporting overcurrent, and that is the BKIN feature. An overcurrent can only be reported by the hardware comparator(s). There is no need for a software based overcurrent monitor, because the FOC algorithm *controls* the current (unless there is loop instability).

So I have to study the driver better.

In fact, I get a bit confused because Renesas used different methods. But I'm enjoying ST.



[EDIT]
During the Motor Profiler tests, the motor is put under more stress and can exceed these currents ...

But tomorrow I will analyze better with the scope what is happening.

[tatus1969]

looks good. but if the current control loop (a PI type controller) is set up well, then it will not exceed the motor's rated current in any situation
 just make sure to set a value smaller than the overcurrent threshold, like maybe 1.8A in your case, in the motor parameters in STMCWB. the PI control gains are calculated ftom the motor specs L, R, but i did not have the impression that the calculations were right so i did my own tuning. the standard procedure here is I=0, slowly step up P until stability starts degrading, then step up I until critical. then i like to set 50% of these values so i have a safety margin. do all this at max bus voltage. maybe the motor profiler does this job as well? will play with it when i have time.

[Dave_PT]

For some reason only yesterday I concluded that I had version 4.2 installed. The latest version (4.3) already has worspaces for AC6.
I was able to import the project correctly, but I can not compile.
This is the message that appears.
Do not you know what might cause this?
I can not find the lib "MC_Library_STM32F302x8_single_drive" anywhere ....

09:39:34 **** Incremental Build of configuration P-NUCLEO-IHM001_SINGLEDRIVE for project STM32F30x_UserProject ****
make all
'Building target: STM32F30x_UserProject.elf'
'Invoking: MCU GCC Linker'
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -L"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled" -L"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\MCO_SD"  --specs=rdimon.specs -T"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\STM32F30x_UserProject\STM32F302R8Tx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -lm -o "STM32F30x_UserProject.elf" @"objects.list"  -lMC_Library_STM32F302x8_single_drive -lMC_Lib_PS_CM4
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lMC_Library_STM32F302x8_single_drive
collect2.exe: error: ld returned 1 exit status
make: *** [STM32F30x_UserProject.elf] Error 1

[Dave_PT]

See page 103 and 104.
I do not have any of these files after installing version 4.3.

http://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_PT]

I installed version 4.2 on another computer and copied the * .a files.

I pasted the files into the "AC6 \ MC Library Compiled" folder, but the compiler still can not find the files.

Then I changed the file name to "libMC_Library_STM32F302x8_single_drive.a", but I have a lot of fails and some undefined references.

It seems to me that libraries are not compatible (has logic), version 4.2 for version 4.3.

Code: [Select]

make all
'Building target: STM32F30x_UserProject.elf'
'Invoking: MCU GCC Linker'
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -L"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled" -L"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\MCO_SD"  --specs=rdimon.specs -T"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\STM32F30x_UserProject\STM32F302R8Tx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -lm -o "STM32F30x_UserProject.elf" @"objects.list"  -lMC_Library_STM32F302x8_single_drive -lMC_Lib_PS_CM4
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(BusVoltageSensorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(CircleLimitationClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(DigitalOutputClass_F30X.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(FeedForwardCtrlClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(FluxWeakeningCtrlClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(MC_Math.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(MCIRQHandlerClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(MotorPowerMeasurementClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(NTC_F30X_TemperatureSensorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(PID_PIRegulatorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(PIRegulatorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(PQD_MotorPowerMeasurementClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(PWMnCurrFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(R3_1_F30X_PWMnCurrFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(RampExtMngrClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(Rdivider_F30X_BusVoltageSensorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(RevupCtrlClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(SpeednPosFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(SpeednTorqCtrlClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(StateMachineClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(STO_CORDIC_SpeednPosFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(STO_SpeednPosFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(TemperatureSensorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(VirtualSpeedSensor_SpeednPosFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
Motor control/MC Application/src/MCInterfaceClass.o: In function `MCI_StopSpeedRamp':
C:/Program Files (x86)/STMicroelectronics/FOC SDK/v4.3.0/STM32 PMSM FOC LIB/Web/MCApplication/src/MCInterfaceClass.c:491: undefined reference to `STC_StopSpeedRamp'
Motor control/MC Application/src/MCTasks.o: In function `TSK_MediumFrequencyTaskM1':
C:/Program Files (x86)/STMicroelectronics/FOC SDK/v4.3.0/STM32 PMSM FOC LIB/Web/MCApplication/src/MCTasks.c:1339: undefined reference to `STC_ForceSpeedReferenceToCurrentSpeed'
collect2.exe: error: ld returned 1 exit status
make: *** [STM32F30x_UserProject.elf] Error 1

[Dave_PT]

All solved so far.

Now the problem is the encoder.

The motor gives a small start, but then stops.

The motor gets "stuck" (current is flowing).

The encoder is already configured but I can not start up with the control.

[tatus1969]

All solved so far.

Now the problem is the encoder.

The motor gives a small start, but then stops.

The motor gets "stuck" (current is flowing).

The encoder is already configured but I can not start up with the control.

you cannot use an encoder as primary rotor angle sensor. until the reference mark is passed the first time, how should the software know the absolute rotor angle? you need an absolute angle sensor, like three hall sensors, or use sensorless startup to have the rotor start spinning. (does your encoder have a reference channel?) another option, but only if there is no load at the shaft: apply current with a given fixed vector, wait some time until the rotor has arrived and stabilized there, the yinitialize for encoder use. i have code for that at home, can send you tomorrow.

[Dave_PT]

My problem is the low revs.
At low speeds the sensorless control does not work because there is no sufficient current through the shunts.
My encoder is a magnetic IC that generates 1024 pulses per mechanical rotation.
This IC also has outputs corresponding to the sensor hall, but I do not think the magnet is calibrated with the rotor.

Monday I will test with sensorless as a primary control and with auxiliary control using encoder.
I'm going to accelerate to 2000 RPM and then I'm slowly going down to 100 RPM. Below the 350RPM the sensorless control can not rotate the motor.

[Dave_PT]

Should I worry about this?

Page 8, 3.2.1 - http://www.st.com/content/ccc/resource/technical/document/release_note/b1/3f/4e/1b/cc/7f/45/c1/DM00068242.pdf/files/DM00068242.pdf/jcr:content/translations/en.DM00068242.pdf

[tatus1969]

My problem is the low revs.
At low speeds the sensorless control does not work because there is no sufficient current through the shunts.
My encoder is a magnetic IC that generates 1024 pulses per mechanical rotation.
This IC also has outputs corresponding to the sensor hall, but I do not think the magnet is calibrated with the rotor.

Monday I will test with sensorless as a primary control and with auxiliary control using encoder.
I'm going to accelerate to 2000 RPM and then I'm slowly going down to 100 RPM. Below the 350RPM the sensorless control can not rotate the motor.

I need some more information to understand your application here:
- does your encoder provide an I channel?
- you mentioned that it is magnetic and has Hall sensor emulation outputs, can you give more information on it?
- can the encoder measure the absolute rotor angle?
- do you need to be able to rev up the motor under load?
- after rev up, do you need to be able to provide torque at standstill?

It sounds like your encoder is a resolver (https://en.wikipedia.org/wiki/Resolver_%28electrical%29). The natural output of these is two analog signals, but many modern ones can also emulate incremental encoders, and hall sensors.

If you have something like this, then it can determine the absolute rotor angle immediately after powerup. If it then provides Hall outputs, then you should go for those instead.

The FOC algorithm interpolates the Hall sensors while the motor is turning, so there will be no degradation. But you have a 10-20% torque loss at very slow velocity (probably far slower than the numbers that you mentioned) and standstill. If that is not a problem in your application, then you'd be fine. And your possible encoder software/microcontroller limitation from your last post would become unimportant (I vaguely remember that I needed to sacrifice a GPIO for that, can check this evening).