Overcurrent Error When Applying Motor Parameters from P-NUCLEO-IHM03 to EVSPIN32G4-DUAL

[pelino]

After obtaining the motor configuration parameters using the P-NUCLEO-IHM03, I applied the same motor parameter values to the EVSPIN32G4-DUAL board, which is used to drive two motors.

However, when operating the motors with these settings on the EVSPIN32G4-DUAL, an overcurrent error occurs.

Could you please explain the possible reasons for this overcurrent condition?
In particular, I would like to know whether differences in the power stage, current sensing topology, or dual-motor operation could cause this issue, even when the same motor parameters are used.

Thank you for your support.

Best regards,
Pelino

[GMA]

Hello @pelino,

Do you mean that you used the motor profiler tool with the P-NUCLEO-IHM03 pack to profile the motor, and after saving the result, you created a new project with EVSPIN32G4-DUAL and the motor profile result?

For Error description and management, refer to documentation available through "Workbench tool">About>Documentations>Documentation>"User manual" tab, "(FOC) Firmware errors" link.

[pelino]

I continuously see the following warning:

NOTICE: Please disable the overcurrent protection of Stage 2 to avoid resource assignment conflict on COMP2. The power stage is already protected by STDRIVE101.

I have already disabled the Overcurrent Protection in Stage 2, however the warning still appears.

Could you please clarify:

1. Is there any additional configuration required to completely remove this warning?

2. Is this warning only informational, and can it be safely ignored if STDRIVE101 hardware OCP is used?

3. Which specific setting or module is still allocating COMP2, causing this notice?

4. Is this warning expected behavior for STDRIVE101-based boards in Motor Control Workbench?

Even after disabling Stage 2 OCP, the message remains unchanged, so I would like to confirm whether this is a known limitation or a configuration issue.

Thank you for your support.

 

[GMA]

Hello @pelino,

This is a warning message to avoid resource assignment conflicts on COMP2 and, as you mention, is independent of OCP usage.
It does not prevent project generation.

[pelino]

 

"C38 and C42 are not populated. Could this cause false overcurrent detection?"

[pelino]

Regarding the Overcurrent Protection,

if the current exceeds the maximum current value of 1.7 A, will the protection be triggered?

 

Also, was the current waveform shown below measured using a shunt resistor?

Is there a way to measure or monitor the current using Motor Pilot instead?

 

Thank you for your support.

 

 

[pelino]

I created an EVSPIN32G4-DUAL project using MK Workbench.

I am currently testing with only one motor connected to the EVSPIN32G4-DUAL.

As shown below, an Overcurrent Fault occurs on Motor 1.

Even after changing the environment settings as shown below, the Overcurrent error still occurs.

 

1. Check of the current sensing topology

 

2. Change the PWM frequency

3. Change the start-up profile

 

4.Modify the sensorless start-up parameters

 

 

 

 

 

[pelino]

Hello @GMA 

Please review my responses.

 

[GMA]

Hello @pelino,

By default, Overcurrent protection and Driver protection use the same BKIN input. Using Overcurrent protection on BKIN2, if Driver protection is triggered instead of overcurrent protection, try using the default parameter settings and close the VDSMON DIS jumpers (open on your attached picture).

An issue might trigger driver protection at startup due to VDS monitoring. This issue will be resolved in the next release.

[pelino]

Hello @GMA 

As you mentioned, when I close J2, the system operates normally.

However, I still do not fully understand the behavior.

I do not understand how Overcurrent Protection and Driver Protection are detected via BKIN,

and how BKIN2 detects Overcurrent Protection.

Could you please explain this in detail?

I would also like to ask about the operation of BKIN.

Looking at the BKIN polarity, it is configured as HIGH.
So I expect that when the BKIN input pin is HIGH, the brake is applied.

MX_TIM1_Init

PE15 is configured as pull-up.

In that case, wouldn’t it always be HIGH,
meaning that the PWM should always be braked?

when checking PE15 as shown below,
it is confirmed that the signal goes LOW when a FAULT occurs.

 

 

MX_TIM8_Init

The BKIN2 polarity is also configured as HIGH.

PB6 is configured as pull-up.

PB6 is connected to M2_nFAULT, and M2_nFAULT is connected to VDD,

so it is always measured as 3.3 V.

Since PB6 is also always HIGH,
wouldn’t that mean the PWM is always braked as well?

Best Regards,

Pelino

 

 

 

 

 

 

[pelino]

Hello @GMA 

I’d appreciate it if you could take a look at my responses.

[pelino]

Hello @GMA 

I understand that BRK2 going low can be caused either by
VDS monitoring protection or by an overcurrent fault detected by COMP1,

which then triggers a break.

Even if BRK2 is designed mainly for Overcurrent Protection,
if BRK2 is also used by Driver Protection to evaluate voltages as shown below,
shouldn’t it be judged correctly under normal conditions?

If so, why does an error occur?
Is this potentially a hardware issue, or is it related to the protection configuration?

Also, when SCREF is disabled,
does this disable only the VDS monitoring protection, or are other protections affected as well?

 

 

COMP2 is used for Overcurrent Protection.

 

According to the block diagram below,
when either Overcurrent Protection or VDS Monitoring Protection is triggered,
the nFAULT output is asserted low.

However, the Control Logic block diagram above does not seem to match
the Break feature block diagram below.

 

In the lower diagram, the BRK signal is driven by the COMP1 result.

In the upper diagram, the Control Logic drives nFAULT instead.

 

Because of this, the two block diagrams do not appear to be consistent.

Does this mean that the block diagrams do not directly map to the actual behavior of the STSPIN32G4,
or am I misunderstanding how these protection paths are internally connected?