MC-SDK 5.Y.4 code generation error

[PCama.1]

Board: Custom STSPIN32G4

Debug port: external STLINK V3

MC-SDK 5.Y.4

CubeMX 6.4

Firmware: STM32 FW V1.5.0

Drive Type: HAL

Target Toolchain: ST STM32CubeIDE 1.8.0

I designed a custom inverter using an STSPIN32G4, with the same topology of EVSPIN32G4, and so that is how I initiate the project in Motor Control Workbench.

I set it up for speed control and hall effect sensors feedback as the primary and only speed sensor. I have used this setup many times before in earlier versions with no issues.

During code generation, I get the following error:

“The ST intranet updater server is unknown: mcucrosselector.codex.cro.st.com�?

 

and also,

“Completed with errors�?

In the main log, I get:

“Generation failed�?

 

The code seems to compile fine in CubeIDE 1.8.0 with no errors.

I run the program on the board using ST-LINK, Connect under different modes: reset, hardware reset, software reset and often I get a tab in CubeIDE saying:

“Break at address "0x1fff4bc4" with no debug information available, or outside of program code.�?

In the console, I get the normal “Download verified successfully�?

The board does connect with Motor Pilot about 50% of the times I try, but immediately I get the following errors.

Finally, from the main dashboard I get an over current fault, but if I click on Acknowledge Fault, nothing happens.

I then run the same process with CubeMX 6.3, I don’t get any error message during code generation, but I get the same error message in Motor Pilot.

Going over the MC-SDK 5.Y.4 release notes, I go in CubeMX, MotorControl Middleware, and set DBG_MCU_LOAD_MEAS, but code will not compile with that option set.

Any suggestions, please?

[MK.1]

Hello. To reduce the number of communication errors, I lowered the port speed to 460800. The errors disappeared.

[cedric H · Accepted solution]

Hello @PCama.1​ ,

Lots of things in your post.

First, the issue at generation phase does not prevent you to generate a working project. The " generation failed" status is then not relevant in your case. I reported the issue you saw to our cubeMX colleagues.

>The board does connect with Motor Pilot about 50% of the times I try, but immediately I get the following errors.

The screen shot of the Pilot you attached does not show any errors but just warnings. Those warnings are not critical but it is true we need to remove them as it brings confusion. From your attachment, I see that the Pilot is actually connected. Could you attach a screen shot of the "Terminal" window when it fails to connect ?

> Finally, from the main dashboard I get an over current fault, but if I click on Acknowledge Fault, nothing happens.

If nothing happens, it means that your error is permanent.

If I understood correctly, you have an over current fault as soon as you connect the Pilot to the board, even before you start to spin your motor. If this assumption is correct, then you have an issue with your overcurrent protection circuit. What is your topology ? Are you using external signal connected to Timer break pin or embedded comparators ?

> I go in CubeMX, MotorControl Middleware, and set DBG_MCU_LOAD_MEAS, but code will not compile with that option set.

We are aware of a compilation issue if you use both position control and DBG_MCU_LOAD_MEAS simultaneously. If it is not your case, please copy paste your compilation issue in this thread. It will help us to fix it in the next release !

Thanks & Regards

Cedric

[PCama.1]

@cedric H​ Wow, thank you so much for your answer, and further questions which really led me to the solution. Knowing that I could basically ignore the error/warning messages, I felt confident to hone in the current sensor topology, and setup.

I just realized that for a long time, I was looking at the setting for an external network gain, not at the embedded over current protection topology. Once I set up the internal amplifying network gain to match my setup, which is different from the EVSPIN32G4, since my board nominal current is 5 Amps, everything worked like a charm.

Even the DBG_MCU_LOAD_MEAS and the USART1 worked fine. My setup is for speed control with Hal sensors. I am writing my own PID position control with an absolute encoder.

Good job everyone, and thank you so much for your support!

Paulo

[PCama.1]

Hi @MK.1​ Thank you so much for your suggestion, it was really helpful during the debug phase. I believe that the connection was more stable that way.

[PCama.1]

One more question if possible. I noticed that the STSPIN32G4 seems to run hot, at around 60 Celsius and it stays at that temperature even after the motor is not running for a few minutes. I believe I have enough thermal vias under its pad.

Do you have any suggestions for me to look if any process is running continuously?

[cedric H]

Hi,

Just a quick information about the UART Baudrate.

There are no software or mips limitation anymore that prevent you to reach the maximum UART baudrate allowed by your STM32. The issues you may encounter are likely due to a bad quality of the RX an TX UART signals. Lowering the baudrate may help as it will increase the pulse width. One thing to try is to enable the UART RX internal pull-up. If you are designing your own board, do not hesitate to add an external pull-up on both lines RX and TX.

For your information, we did some tests at almost 10Mbps but this speed is highly dependent on the signal quality.

Last point, that is worth to know, is why do we set by default the baudrate at almost 2 Mbps. ?

The reason is exclusively for the datalog feature that allows you to view or record algorithm signals at PWM frequency without any loss.

with a PWM @20Khz, 1843200 bps will allow you to view 4 x16 bits values without any loss. Of course, if you do not need this datalog, or if you need less signals simultaneously, reducing the baudrate is a good strategy.

Hope it helps.

Regards

Cedric

[cedric H]

Hello Paulo,

Thank you very much for your feed back, and happy to read that your system works as expected.

Cedric

[cedric H]

> Do you have any suggestions for me to look if any process is running continuously?

Well, the first thing I would check is the power consumption of your system with a laboratory power supply, and check first that the consumption after a power on reset is the same than once your motor is stopped after spinning. Even if there are rooms for improvement on software side (as we do not enable any low power feature) , I will try to fight for these micro Amps once everything else has been checked.

Cedric

[MK.1]

Thank you very much for the useful information on choosing the connection speed and improving the stability of the connection.