I don't know if it still helps, but researching on BTS7960, I found this link with images of 3 situations that show a table below the Driver image.
In all 3 the image shows a combination of RPWM and LPWM and the combination at the end is written below "BURN"
I still can't quite understand why the author wrote this, but it could be the reason for burning his modules. https://drive.google.com/drive/folders/1unto2Ejn3RgB8B4dK0pyAlSDomYU6veP
I will attach the images for easy viewing.
Just found this topic. Can't tell how old it is but here goes.
I've worked with the BTS7960 and the replacement BTN8960/8962 for years. Couple of points:
You cannot command them into shoot-through. Each device has one input and the output is either high or low and it follows the input. You cannot cross-conduct a single BTN7960.
If both inputs are the same on an H-bridge configuration with 2x BTN7960 that doesn't "Burn" as someone posted. The worst you get is nothing. The output of the BTN7960 can either be VBatt+ or VBatt- nothing else except floating if the Enable is low. The motor only sees the difference in the outputs. If the outputs are the same the motor doesn't see any drive.
You cannot overload the BTN7960B to destruction. It will overheat and safely shut off. Then restart when it cools and the Enable line is pulsed low then high - see the datasheet. It is very robust in this way.
To get the motor to move in an H-bridge the Enable inputs should be held high and PWM-A and PWM-B should be different polarity. Don't pulse the enables and hold the PWM inputs at a DC level. Some old driver chips can do this. The BTN7960B doesn't work that way.
Now looking at your application. Here are my guesses as to what is wrong.
AC/DC power supply. These simply will not withstand reverse current. Large motors like those will blow an AC/DC supply and/or the motor driver easily. All you have to do is quickly slow the motor. The Back-EMF generated by the motor will be higher than the applied voltage from the BTS driver and current will flow back into the AC supply which will spike its voltage upwards to keep current flowing out. This can exceed the maximum voltage of the BTS very easily. That is my best guess as to what caused your units to burn up. The BTS is very sensitive to over-voltage. The newer BTN8960 is better but still not immune.
Ground Loop: According to the diagram you have a ground loop across your fuse. This fuse is a resistance and will have a voltage drop. Your DC converter is connected on one side of the fuse and the BTS drivers ground on the other. Bad news! Connect all grounds at a single point! YOU DO NOT NEED A FUSE to protect the BTS7960B. Other components perhaps but not the BTS7960.
I am also planning a product on these motor drivers. It would be more logical if the driver would be controlled by signals DIR - direction of rotation, PWM - speed of rotation and ENABLE - operation permission or STOP. Such drivers exist, e.g. MD13S. From a reliability point of view this conversion of control signals is better to do in a hardware implementation, which will require a couple of TTL logic circuit cases. Then in case of any errors in the program there will not be emergency modes and equipment failure. Now I am busy developing such a harness for the BTS7960B.
You are of course right in that you can control these drivers purely programmatically, but in relation to the established mode after the program is loaded in the microprocessor. However, there are other situations. I will give you an example: I control the motor by setting the timer in Fast PWM mode, but before my program gets control in setup some standard setting of the timer registers is done and this leads to the fact that when you turn on, once, a short unplanned motor start occurs and you can not fix it programmatically because it has not yet received control at that time. It is necessary to use external hardware. And since this driver has conflicting combinations of input signals, there is a desire to remove these conflicts in principle, that is hardware, by external elements that can be controlled from the program.
