Overcurrent protection hardware feature not showing

[LLang]

[VERSION]: 6.2.1
[TOOL]: MC WB
[DETAILS]:

We are making a custom PCBA based on a STm32G474METx. Algorithm is FOC.
I'm trying to activate Over current protection, but:

My hwVariant is (parameters are not tuned/configured yet)

"type": "SingleInput_RawCurrents_Protection_IntRef",
"help": "Default Configuration",
"signals": {
"CURRENT_INPUT_P": [
  {
	"name": "PB13",
	"help": "",
	"cost": 0
  }
]
},
"OCNetworkGain": 1,
"OCNetworkOffset": 1,
"OCComparatorThreshold": 1,
"OCSignalPolarity": "Active high"

Current sensing is defined as:

  "type": "TwoICSCurrents",
  "help": "How to enable this variant",
  "signals": {
	"CURRENT_ICS_U": [
	  {
		"name": "PA0",
		"help": "",
		"cost": 0
	  }
	],
	"CURRENT_ICS_V": [
	  {
		"name": "PA1",
		"help": "",
		"cost": 0
	  }
	]
  },
  "icsGain": 0.004

All features other than over current protection are shown as expected.

For reference; full current sensing tab:

How should I configure my .json to be able to activate over current protection?

[EXPECTED BEHAVIOR]:

Being able to activate over current protection in MC WB

[cedric H · Accepted solution]

Hello @LLang ,

The SingleInput_RawCurrents_Protection_IntRef is actually an implicit feature that comes with the Raw current sensing feature. It means that when we use an internal OPAMP if we have a comparator available in the same pin, the WB proposes automatically the Overcurrent protection feature.

ICS is already an amplified current connected directly to an ADC. For this configuration we rely on the driver protection that most of the time propose a fault detection.

If you do not have a fault detection available from your driver, and do not have other choices than using internal comparator based on amplified signals, then you can configure it directly from cubeMX starting from the IOC generated by the WB, and re-generate your project directly from cubeMX.

Let us know if you face any difficulties to achieve this.

Regards

Cedric

[LLang]

Ok, thank you. That explains why I could not get it to work. I guess I'll implement it "manually".

Is this requirement for OCP mentioned somewhere in the documentation that I might have missed?

[DMeie.2]

What are the limitations that hold back the MotorWB from enabling the OCP on an already amplified current signal if a comparator is available on the same pin?

Isn't the idea of the MotorWB that I don't have to implement those features by hand?

[cedric H]

Hello @DMeie.2,

From technical point of view, nothing.

You are right, it is the idea of the WB to do that for you. But our primary goal is to guarantee you that the generated code will be fully functional. In order to do so, we focus first on topologies used by the ST boards, that we can test. As the number of series and the number of boards increase, the number of possible combinations increases exponentially. In our boards, so far, we use the comparator only on non-amplified current. 

Doing it with cubeMX is the best solution we can propose so far.

Regards

Cedric