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

[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?