STM32L4 TIM1 PWM Break lock, interrupt and software trigger

[Amper]

Hi!

I did try for a day myself and asked several people who usually know the way but i cant get a solution so im asking here even though i dont like asking softwarestuff.

Im working on an stm based FOC motor controller, it works nicely and im now concerned with safe shutdown and errorhandling.
The Break input is used in an interlock loop, already working nicely and bringing the entire thing to a safe stop in case the estop is triggered. It turned off all 6 PWM channels by hardware and the motor coasts to a stop, break is done in software for other applications.

However i would really like to use this feature for the other fault conditions as well, right now DClink overvoltage detection just sets all PWM to the same Value, locking the motor, a path to stop this from happening would be to turn all pwm outputs to normal outputs, disabling the timer and setting everything to low, but id prefer to just trigger the break function by software, always ending up in the same errorstate with the heavier fault conditions instead of writing a dedicated function for all of them.



This is the relevant section from the app note, is there really no way of triggering this by software?

Other not so pressing issues are:
Whats the way to reset this state by software? Is there any? Is there a way to check if this fault was triggered? Id like to know in the program to have an error state available in modbus and set the red fault LED, but im so lost in the documentation i cant even find that, i know its a case of RTFM but i did all day and just cant find anything useful...

cheers


EDIT: i did try to get the TIM1 Break Interrupt to fire to set a flag but that didnt work for some reason. Polling would be nicer anyways in my case since there is already a bunch of interrupts active and i dont want them to collide at some point.

[wek]

One day of reading the manual may not be enough; it's a complex functionality.

Read Using the break function in TIM1/8 chapter in RM:

Break events can also be generated by software using BG and B2G bits in the TIMx_EGR
register. The software break generation using BG and B2G is active whatever the BKE and
BK2E enable bits values.

That chapter describes also what happens with the related pins in case of Break, what configuration bits influence this behaviour and how; and also the methods to "release" Break.

See also the Output control bits for complementary OCx and OCxN channels with break feature table and description of TIMx_BDTR register. I presume you are already familiar with the "normal" Output Compare module operation and thus features set up with TIMx_CCMRx and TIMx_CCER. If you've clicked your program in CubeMX, then start with reading those chapters to understand the Output Compare.

I recommend to start with a simple program, perhaps on a Nucleo or Disco board (so that you are not distracted with the attached power electronics), instrumenting one TIM1_CHx/CHNx pair with a resistor divider pulling it to mid state (so that Hi-Z can be distinguished from pulled-low and pulled-high), and observing its state on oscilloscope (a poor developer's replacement can be devised by two LEDs with sufficient Vf (or LED in series with a diode), one to GND and other to VDD (with series current-limiting resistors of course)). Then write a bunch of simple experiments with all features described in that chapter and observe the resulting behaviour.

JW

[Amper]

Thank you! Thats exactly what i was looking for but just couldnt find for some reason.

Yes, im more or less familiar but yes, also i just clicked things together. This is a section of a larger project and i just have to get things to work, not do real software engineering. I did play around a bit by changing the generated code and using it as a basis but i couldnt write it myself entirely for stm32, on old atmels i know my way around, but this is sort of new to me and a bit too complex for casual use.

Regarding hardware i have the working prototype, the power side was made to be close to indestructible with external dead time generation, interlocks and components that can handle essentially anything a large power supply can throw at it, using 300A 1mR5 FETs and a very good layout done by a friend of mine by constraints we set together, also things already work well in that respect, before doing our own hardware i used bldc fan controllers as prototyping platform, killed a few, learned a lot, the power side is good enough now to dare putting a 250F 24V capacitor bank on it for having two quadrant supply.

It now works with asynchronous and BLDC , next steps after completing rs485 communications and the E-Stop will likely be a transition to
trapezoidal commutation for high speed drives as the main reason for doing this entire project is that we are really not happy with the "open source" projects out there that are either not really open, are very buggy or just not fitting our applications in controlling essentially all kinds of "i found this *thing* at the scrapyard today, but the inverter is missing".


I did two shaky videos a few days ago for an impression:





Ill post here if things work

[wek]

> "open source" projects out there that are either not really open, are very buggy or just not fitting our applications in controlling essentially all kinds

They are not really open, very buggy, or not very flexible, exactly because

> This is a section of a larger project and i just have to get things to work, not do real software engineering.

Doing things flexible and good requires lots of engineering, read: time, read: money. The motivation for open sourcing is just that much, even if it's not just altruism and self-promotion, but is based on some business model (which in turn is inevitably limited by the potential audience, etc.etc.).

Clicking in CubeMX (or, for that matter, ST has also some clicky motor control framework, I don't know much about that) yields quick results as long as your application fits whatever those clickies author's deemed typical, as their scope/time/money is inevitably limited, too; so the clickies inevitably cover only a miniscule fraction of the almost infinite ways the hardware can be used. If this "fit" happens, you are a happy camper, end of story. But whatever does not fit, you have to go back, relearn what you didn't want to learn at the first place, and then either bend the clicked result (which may or may not lead to desired result), or try to unlearn what you've experienced with the clicky and walk all the path you've deemed hard at the beginning (which is psychologically next to impossible).

And now you've been warned.

JW

[Amper]

Yes, im aware of that, thats why i got to this point easily and now only wit some assistance. Im not trying to use the controller to its max, just one or two unusual features.

Of cause open source projects wont fit everything nicely, im not trying to call them bad, they just dont fit my needs, for example im no aware of any using this festure i was asking about, so i roll my own that i can taylor to what i need. SimpleFOC ist the flosest to what i need, others are VESC and Odrive wich by now both are pretty much closed source and useless, as well s bloated and wont run on the supply of several hundred L4 controllers i already have laying around