• 状态 Resolved
  • 已锁定 已锁定
  • 回复 2 回复
  • 订户 1 订户
  • 视图 194 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] LAUNCHXL-F280049C：SDK 死区

admin
Guru**** 2526890 points
Other Parts Discussed in Thread: DRV8320

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/894973/launchxl-f280049c-sdk-dead-band

器件型号：LAUNCHXL-F280049C
主题中讨论的其他器件：DRV8320

偏移调节开始时电压瞬态的意外击穿、使两个 NFET 短路。

幸运的是、NFET 的死区时间典型值为100ns、但死区延迟设置为180ns (hal.h)、与6步相同。

1. HAL_setupPWMs()死区集(TRUE)是否会导致内置死区或 PWM 生成的 drv8320rs 出现问题？

与良好的寄生信号相比、两种死区延迟配置可能会重叠并造成更大的损害。

2. SVPWM 是否需要比6步20kHz 50µs 周期更长的死区时间？

3.调用 HAL_setupPWMDACs()， 是否以某种方式使之前对 HAL_setupPWM()的调用失败，并将 ePWM 发生器死区恢复为禁用状态？ 

//设置死区发生器控制寄存器(DBCTL)
ePWM_setDeadBandDelayMode (obj->pwmDACHandle[cnT]、ePWM_DB_RED、false)；
ePWM_setDeadBandDelayMode (obj->pwmDACHandle[cnT]、ePWM_DB_FED、false)；

  • 0
    TI__Guru**** 2526890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    1.不 如果 C2000和 DRV8320都启用了死区时间、则最终死区时间是它们之间的最大设置数。

    2.不 SVPWM 与死区时间无关。

    不可以、PWMDAC 应该使用不同的具有电机控制功能的 ePWM 模块。

  • 0
    TI__Guru**** 2526890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    [引用用户="Yanming Luo ]1. 否 如果 C2000和 DRV8320 都启用了死区时间、则最终死区时间是最大设置数。

    因此、两个器件都将向现有边沿添加红色/馈送延迟时间、这将使边沿延时时间延长一倍。

    这意味着为 drv8320rs 设置了200ns 的死区时间、似乎解释了为什么要持续180ns。 NextFETS 具有 TRR 36ns、为什么是200ns？ 栅极饱和似乎更大、SVPWM 需要更长时间才能确保开关确实关闭？ 由于各种原因、SVPWM 的开关松动会更大。

    [引用用户="Yanming Luo ]2. 否 SVPWM 与死区时间无关。[/QUERP]

    奇怪 的 SPRUHJ1H 故障排除指南显示 SVPWM 的> 2µs Ω。 Cypress SVPWM 套件为10kHz 调制设置死区800ns。 对于 SVPWM 而言、似乎有一些更长的关断时间、6级不会出现这种情况。 想要对为何该行业将死区时间设置得如此之高以实现这些更快的 NFETS 进行科学评估。

    [引用用户="Yanming Luo ]3. 否、PWMDAC 应该使用不同的具有电机控制功能的 ePWM 模块。

    我看到了这一点、但了解了180ns 死区时间如何通过50%占空比偏移计算导致击穿。 在1/2电桥 ST 之后将死区时间增加至220ns、但尚未再次测试。