Trouble with STEVAL-STSPIN3201

[DHemb.1]

First, I am new to this board and to development using ST products.

I have identified the STEVAL-STSPIN3201 as being the platform most suited to the project I am involved with and have attempted, unsuccessfully, to use ST Motor Control Workbench 6.1.1 to generate code to upload to the 3201. Below are the steps I followed:

• I started a new project, selecting 1 motor, FOC, Inverter
• Select GBM2804H-100T for the motor
• Select the STEVAL-STSPIN3201 as the power board (inverter)
• Change Max Application Current to 2A
• Change Bus Voltage to 12V
• Save and click Generate the project (STM32CubeMX: 6.4.0, Target Toolchain: ST STM32CubeIDE, Firmware Package Version: STM32 FW V1.114 (Recommended), Drive Type: HAL)
• Completed with Errors: CLASS='Data Exchange' GROUP='STM32_MetaDataManager, GROUP='STM32_MetaDataManager' CLASS='Data Exchange. Research I did seemed to indicate these errors would not affect the outcome. I'm not certain.
• Select RUN STM32CubeMX (STM32CubeMX opens)
• Select GENERATE CODE (code successfully generates)
• Select Open Project (STM32CubeIDE opens)
• Project is successfully imported
• Highlight imported project and select Build Project which results in the following errors:

...STPIN3201.elf section `.data' will not fit in region `FLASH'

...region `FLASH' overflowed by 364 bytes

make: *** [makefile:66: STPIN3201.elf] Error 1

Following these errors I am unable to proceed. Is there a step-by-step procedure I can follow that differs from what I attempted above? What am I missing? Is there proven code as an example project that I can use to successfully upload to the board and run?

Any help is appreciated.

[DHemb.1]

The support on this forum is stellar. I think it's time to look at other options besides ST.

 

[Fred V.]

Hello GHemb.1,

The error you get is due to the fact that the firmware you are building doe not fit into the small Flash memory of the STSPIN3201. This is the kind of thing that you discover at build time. 

You can work around this issue by de-activating the Motor Control Protocol: Set "Over USART A" switch to off in the User Interface section of the workbench.  With this disabled, the firmware will build. However, you will not be able to connect to it through a serial port and you will not have the capability to control the motor with the Motor Pilot PC tool. Only the button and potentiometer inputs on the board may be used to control the motor, but you need to mount them (J8 and J9), or you would have to write some code.

Activating the potentiometer for speed reference setting can be done in the Stage Configuration section of the Workbench. 

With Motor Control Protocol disabled and the potentiometer enabled, the code builds and fit into the flash.

The other issues you saw ("Errors: CLASS='Data Exchange' GROUP='STM32_MetaDataManager, GROUP='STM32_MetaDataManager' CLASS='Data Exchange") indeed have no impact on the code generation. 

And you do not need to open CubeMx after workbench generation unless you want to change the hardware configuration of the MCU.

One last thing: make sure to build with the "Release" configuration of the project. 

Best REgards,

Fred V.

[DHemb.1]

Fred V.

Thank you for the reply.

Following your instructions I am now able to build and upload the code to the board. I have disabled USART comms and ensured both the pot and the USER1 button and their associated GPIO pins are enabled.

Within the STMCubeIDE I highlight the project and select Run As>STM32 C/C++ Application>STSPIN3201.elf (release)>OK.

Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
-------------------------------------------------------------------
STM32CubeProgrammer v2.13.0
-------------------------------------------------------------------

 

Log output file: C:\Users\danhe\AppData\Local\Temp\STM32CubeProgrammer_a02592.log
ST-LINK SN : 066DFF565348726587082621
ST-LINK FW : V2J40M27
Board : --
Voltage : 3.17V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x444
Revision ID : Rev 1.0
Device name : STM32F03x
Flash size : 32 KBytes
Device type : MCU
Device CPU : Cortex-M0
BL Version : 0x10

 

Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a02592.srec
File : ST-LINK_GDB_server_a02592.srec
Size : 21.76 KB
Address : 0x08000000

Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 21]
Download in Progress:

File download complete
Time elapsed during download operation: 00:00:01.651

 

I verified the upload using the STM32CubeProgrammer.

I would expect that something would happen when USER1 is pressed, but the motor does not budge, even with varying rotations of the SPEED pot. I have not altered any other parameters within the workbench.

 

Any ideas?

 

Verifying ...

 

Download verified successfully

Shutting down...
Exit.

 

 

[peepn61]

Hi,

I had the same problem when started. You can check for compiler optimization options under Project/Properties. Using Uart is important, it grants the Motor Pilot

[Fred V.]

Hello,

Yes, using the UART is important since it allows for controlling and configuring the application without changing its code, thanks to the Motor Pilot. However, the drawback of it its that it requires some Flash memory for the code and , for some devices with a little Flash memory it may be too much. 

You can try to play with the optimization level by replacing -OFast with -Os as displayed below. However, you may have to lower the PWM frequency for the motor to spin with no error.

Best Regards

Fred

[Fred V.]

Hello,

Indeed, setting the potentiometer half-way and pressing the button should result in the motor spinning. Now, your application may need some tuning, or there may be some other issue.

One first thing I would try, would be to let the application run for a second or two, after power on, without pressing the button and then, stop the execution with the debugger and check the following items

• In the global structure Mci[0], members CurrentFaults and PastFaults should be set to 0; Otherwise, the application has detected an error. These two members are bit fields that indicate the error(s) that have occurred. You can find the definition of the errors in mc_type.h around line 91+ (look for MC_NO_FAULTS).
• If both error members are 0, place a breakpoint in the MCI_StartMotor() function, resume the execution of the application and press the button. The breakpoint should fire which indicates that the button press is handled. Otherwise, there is an issue with button handling. Then, you can add a call to the MC_StartMotor1() function, in the main() function, right before the while(1) statement in the /* USER CODE BEGIN WHILE */ section.
• Resume code execution, wait for a second or two and break again. Then, you can check for the values of CurrentFaults and PastFaults again. If they show errors then, you may need to tune the motor start-up parameters in the workbench (Speed Sensing --> Sensorless start-up parameters). 
• Also check the MCBootCompleted variable defined in mc_tasks.c. It should be set to 1, indicating that the motor control subsystem is properly configured. If that is not the case, there is probably an issue with the initialisation of MCU peripherals.
• What code is being executed at debugger break time? If the code is in the HardFault_Handler function you would need to debug, step by step the startup of the application to understand what leads to this situation. 

That is all I can think about without having my hands on the setup.

Best Regards,

Fred

[peepn61]

Could you please comment in the same depth? Speed Sensing --> Sensorless start-up parameters

In my case Overcurrent or HardFault_Handler

[Fred V.]

Hello @peepn61 

Not sure I understand your comment on the depth.

Which error do you get? OverCurrent or HardFaultHandler? You're mentioning the Sensorless startup params. Did you play with them to tune your setup? Did you get you error(s) during the startup phase?

Best Regards,

FredV