microcontroller and software current limiting

[iAmHere]

Hello guys,

I'm working on a project with a 32 bits microcontroller..
I would like to limit the current drawn by the MOSFETs by measuring the current consumed with an ACS71240KEXBLT-010B3 ( https://www.allegromicro.com/~/media/files/datasheets/acs71240-datasheet.pdf ) . This component measures the current in +/-10A and sends a proportional voltage to the microcontroller.
I would like to know if this solution can replace physical fuses for an industrial application

Thank you for your feedback

[Marco]

Do you really want to do electronic fuse operations on some 32 bit microcontroller, one likely doing control tasks with a ton of interrupt related code and with relatively frequent firmware updates? You trust your coding more than I do mine.

[Brage]

I'm with Marco here. There are too many reasons for the micro to NOT be able to act as the fuse. A fuse from a reputable manufacturer is tried and tested component, why redo all the work?

If you really like the idea of having a software fuse, would it be an option to have both? Using a (hardware) fuse as the absolute maximum, while also using the software fuse set at an lower threshold.

[moffy]

I agree with both Marco and Barge, a fuse is a fundamental safety feature, to prevent fire etc., a micro can sometimes get lost executing code and fail performing this essential function, or just not quickly enough. It's not just that the micro isn't really suitable it is also the liability you are exposing yourself to for a fundamental safety feature.

[SiliconWizard]

The IC the OP showed has a hard fault output with fixed tripping points. So instead of purely relying on software, one could use it to switch off power transistors directly (so purely hardware), while monitoring the current measurement in software for logging/early "failure" warnings/whatever.

Now whether a hardware switch-off is less "safe" than a fuse - certainly semiconductors have certain failure modes that fuses do not exhibit, so it will never quite be as safe as a simple fuse.
But you could use both, with a lower tripping point in the above IC than in the fuse, and still a fuse in case things go really wrong. Just a thought.

[Marco]

There's dedicated eFuses too, with build in charge pumps so they can use N-channel only, thermal protection, inrush current limiting and of course overcurrent interruption.

If you have very special needs I could see implementing an electronic fuse yourself on a microcontroller, but a dedicated one, a really simple one.

[nctnico]

The IC the OP showed has a hard fault output with fixed tripping points. So instead of purely relying on software, one could use it to switch off power transistors directly (so purely hardware), while monitoring the current measurement in software for logging/early "failure" warnings/whatever.

Now whether a hardware switch-off is less "safe" than a fuse - certainly semiconductors have certain failure modes that fuses do not exhibit, so it will never quite be as safe as a simple fuse.
But you could use both, with a lower tripping point in the above IC than in the fuse, and still a fuse in case things go really wrong. Just a thought.

I agree. Current limiting is best done in hardware and will be necessary to protect a MOSFET fast enough. Some microcontrollers (NXP has some) have hardware inputs to their PWM controllers which can shut down an output without software intervention. An analog comparator to detect the trip level is all that is needed drive such an input. Such a mechanism is still subject to the clock running and proper software initialisation.

A physical fuse will always be required to protect against fire (= protect the circuit from going up in flames).

[Siwastaja]

Do you really want to do electronic fuse operations on some 32 bit microcontroller, one likely doing control tasks with a ton of interrupt related code and with relatively frequent firmware updates? You trust your coding more than I do mine.

Ever heard about interrupt priorities? One line of code per interrupt source and your "ton of interrupt related code" argument just goes away. Regarding firmware updates, maybe turn the outputs off before starting the flash? This is all utterly trivial, done that many times.

Reliability and safety are relative, it is never perfect. The key is to understand how reliable certain solution is and is it good enough.

In a pinch, routing the FAULT pin to an interrupt pin and configuring highest-priority interrupt does the trick quite reliably, but still that depends on things like oscillator not failing. Relatively speaking, done right, it's very reliable but not totally infallible.

One step up is to route FAULT to the PWM/timer module etc. which offers such input. Asynchronous is better. Assuming the peripheral is properly designed and you understand how to configure it, this could be more reliable, but still depends on the code to configure it right, and not accidentally change the configuration.

Going even further, use external latch IC, requiring manual reset or something.

This all depends on the failure scenarios. Sometimes it's acceptable that an extremely rare failure blows the FETs, the fuse, and the whole unit is swapped.

Traditional fuse with sufficient interrupt current and voltage ratings (DC rating in case of DC source) is a must for fire protection.

[EPAIII]

Some random thoughts after reading this.

Instead of using a microcontroller, why not just use a Voltage regulator with fold-back current limiting? Would it not react fast enough? It seems it should be faster than code. Is it the cost? A few extra pennies?

If the circuit is properly designed and working, WHY would you want to install firmware updates which may introduce a problem? Couldn't a working circuit and software just be left alone?

On that "one line of code per interrupt source" thing, how do you KNOW you will have all of them covered? And could a firmware update possibly introduce one or more new interrupts which your original code did not negate? I don't know, just asking.

No matter what, I do agree that a hardware fuse is still required.

[Siwastaja]

I mean, this is a fairly reliable pattern:

Code: [Select]

interrupt_handler()
{
   output register = low
}

main()
{
    // use pulldown resistors on outputs
    enable gpio clocks
    output register = low
    gpio direction = output
    NVIC_SetPriority(..., 0);
    NVIC_EnableIRQ(...);

    only now start turning output high.
}

Of course you can accidentally do a new software modification, adding another interrupt source, accidentally give it the same priority...

But you can also accidentally miswire the hardware solution!

Keep critical parts of the code simple and your eyes open.

Regulator with current limiting is completely different than e-fuse. Sometimes you want the e-fuse. It's more accurate and faster than classic fuse, and in addition, resettable. E-fuse can even protect semiconductors.

But even the e-fuse needs an actual fuse for fire protection in case the e-fuse has a design mistake.

Though, from OP's decription, they don't likely talk about e-fuse, but current limiting in inductive load such as DC/DC converter or motor controller. In such case, wiring the overcurrent signal to the BREAK input of the TIMER module of the MCU is exactly the right thing to do, and in a pinch, interrupt-based solution replaces that if the MCU is too simplistic to implement the break input.

[Marco]

Ever heard about interrupt priorities? One line of code per interrupt source and your "ton of interrupt related code" argument just goes away.

Now create an automated tool to make sure no one gets lazy or sloppy with interrupt masking, priorities and I/O mapping.

Regarding firmware updates, maybe turn the outputs off before starting the flash? This is all utterly trivial, done that many times.

That's not my problem with the updates. Every update is another opportunity for stupid mistakes and rush work.

Relying on mere coding convention to protect the critical operation of the device if the code is being tinkered with all the time is going to fail. Writing tools to provide guarantuees almost impossible.

[Marco]

If the circuit is properly designed and working, WHY would you want to install firmware updates which may introduce a problem? Couldn't a working circuit and software just be left alone?

Because OP mentioned a 32 bit micro it seemed to me part of a multipurpose system. A computational efuse requires only trivial processing, some 8/16 bit micro with minimal flash can handle it.

[Siwastaja]

Oh, don't try to mix random uncontrolled application development and safety features on the same MCU.

Welcome to 2000's, 32-bit MCUs have been used for low level control applications for two decades or even longer, even for safety-critical applications, replacing 8-bitters not completely, but pretty much. These 32-bit parts tend to have better safety features built in. So using a 32-bit ARM is just normal, doesn't tell anything about the system.

Typical examples are motor drivers. You can easily make power stages explode by wrong code modifications. This is the reality, and it makes no sense to try to create perfect HW barriers against random programmers. The usual way to do is, is to configure the asynchronous break signal (rare in 8-bitters) to cut PWM. This is "hardware solution", but configured by software. Just change the init code to not enable this feature, and bang!

Solution: don't do that.

If you do that anyway, fire the guy who did it.

Sounds too simple-minded? Create a quality assurance process.

The assumption that HW designers are infallible and FW developers are morons, and the HW guys protect against FW mistakes, just does not work out. It's almost never done that way.

Welcome to safety critical software. And yes, there actually are processes to guarantee safety and correct function. Look at automotive firmwares, for example ABS brakes. It's much more complex than e-fuse, and safety processes existed already in early 1990's. Or aviation in general. Pretty much of software where a simple mistake can kill people, with no HW safeguards anywhere. Completely normal.

But you don't need to go that far if the project is simple or small and not responsible of keeping people alive. For example, if the worst that can happen is a blown MOSFET and the actual fuse protects against damage (other than the MOSFET), no need to stress about it, just if that ever happens, replace the module and learn from the mistake. If the worst that can happen is overcharged li-ion cell and small risk of fire, then you need to be much more careful and some quality assurance process might be a good idea. If it's MCAS, then you need to actually prove the safety need not worry either .

If the OP wants fancy applications on the top of the critical core, it's best separated on two separate chips, actually. Separate UI processors are normal industry practice.

I prefer one-CPU solution, but then again, I take the responsibility if I make a mistake.

And yeah, many MCUs implement lock bits so that critical peripheral configuration is hard to change by accident (for example, by wrong pointer - extremely unlikely to hit the particular register, but possible). But these are mostly the feared 32-bitters.

[nctnico]

Traditional fuse with sufficient interrupt current and voltage ratings (DC rating in case of DC source) is a must for fire protection.

I've seen that fail as well in a rather spectacular way    But I will admit this was in a totally unrealistic case.

[iAmHere]

Hello everyone, thank you for your very informative comments.
My idea was not to use a 32bit microcontroller just to have a programmable fuse function. This microcontroller exchanges data in bluetooth with a smarthpone.
Circuit protection is provided by a general 20A-12V fuse. This fuse has been planned since the beginning of my project.
I wanted to protect 4 MOSFET outputs which can deliver a current of 10A but of course which will not all work at maximum current. I will provide 4 fuses for the 4 outputs to have selectivity and abandoned my initial idea.
I saw that there were e-fuses whose current limit can be set with a resistor.
If I use e-fuses, do I still have to protect the 4 MOSFETs with physical fuses while there is the 20A head fuse?

[nctnico]

No. As someone already wrote: fuses (as in the ones that burn a thin wire) are way to slow to protect a semiconductor. A fuse is a device to protect against fire.

What you will want is current limiting which acts as fast as it can. Fast = sub 1 microsecond. You have to make sure the e-fuses are up to such a task. Maybe current limiting is more appropriate.

Perhaps you can share more details about the type of load, operating voltage and how the MOSFETs are driven. IMHO the ACS71240KEXBLT device is expensive and slow. A current sense resistor + current sensing amplifier could be a better solution. You can even resort to measuring the voltage across the MOSFET instead of a current sensing resistor. Not very accurate but if you make sure the worst case situation doesn't exceed the SOA of the MOSFET you will be fine.

[Siwastaja]

Consider load switch ICs. Completely engineered solution with MOSFET SOA and die temperature monitoring, comes with a simple fault status output indicating overcurrent happened and output was shut down.

Roll your own only if you have special requirements, or if you want to learn how to design a load switch.

What are the actual loads the MOSFETs will control?

[iAmHere]

The MOSFETs  ( current consumed from 1 to 10 A max )  will be "versatile", they can drive LED lights, resistors,USB chargers or inductive load, it will depend on the need desired by the user.
To make sure the wires don't catch fire, I'll let users choose the fuse ratings for their final application.

[Brage]

There are IC load switches that are current programmable. They are usually intended for switching applications, but you can just leave them on and only switch them off when desired (via MC or w/e). Some of these load switches have internal current sensing and will accept a shutoff threshold as an input. The main benefit is that these guys is that they are fast; µs range fast. Beats the hell out of a lot of fuses. Usually adds a bit to the BOM cost, as far as I remember.
I have not looked at these kind of parts in a long time, so I did a quick search on Digikey to try to find something that is not obsolete. Unfortunately the availability is low with the market being as it is.

Take a look at the AUIR3314: https://rocelec.widen.net/view/pdf/me5qytqgjf/IRSDS11548-1.pdf
The programmable range is from 6A to 58A, so not within your range of 1-10A, but I'm sure there are other models more suited to your need.

But again, as mentioned above and by others, I'd recommend using this in conjunction with a standard fuse.

[iAmHere]

@Brage

I had seen this kind of components but the trigger current is set with the value of the resistor Rifb in the given link.

[poorchava]

Software safety features are a reality and that's a fact. Most bigger appliances have some CPU that has a safety certified code.

A bad update where somebody accidentally deactivated safety critical code is just an invalid pont. That's what QA process is for. No sane company will release a firmware update for a thing that deals with safety features without extensive testing beforehand, and the safety features would likely be the first thing to be checked.

Many CPUs have a way to lockout certain parts of the flash. Mostly, this is used for code which has to be certified, which is mostly money / tax related stuff (think energy meters, gas pumps etc) but also for safety critical stuff.

Tldr: this is definitely doable, but requires some QA and experience to do correctly.

Btw, I have a project, which is essentially a large SMPS (3kW) and the primary current limiting is done with cpu using hardware module + software. Actually cutting the drive to FETs abruptly is exactly what can blow them up. A procedure needs to be followed to do it gracefully.

This saved out he thousands of times and we haven't yet managed to blow the primary bridge since this was implemented (and we tries REALLY hard)

[Siwastaja]

I also had a project where I wanted to reduce the inductor current by driving the freewheeling transistor for some microseconds instead of hard shutdown.

Trivial in highest-priority software interrupt, with simple blocking delays.

Oscillator failure is the biggest concern, but that's exactly why modern MCUs come with clock safety systems which can automatically switch to internal RC oscillator, less accurate but able to do safe shutdown.

I haven't blown a single MOSFET in many years, this is because I start by testing the overcurrent and overvoltage safety circuits (including software!) thoroughly. It's often just a few hour's job when the project is small and software is handled by one person, and no one requires formal testing reports.

I'd say, an individual or a small startup, assuming not actually dealing with human life, does not need to be concerned about safety QA processes. Just make the safety critical configuration the very first thing in main(), and clearly indicate with comments: do not modify this. The risk that you develop a brain malfunction big enough to change that part, and then put it in production without testing it, is of course possible but very very improbable.

Once your business gets bigger, you can think about processes how to prove that safety critical parts are not rendered inoperative. Proving safety is always very difficult, even in seemingly simple solutions.