[参考译文] DRV8353RS-EVM：100 安培 NexFET 新电路板 eSMO 在崩溃后短接

您好：  

你能确定这是一个短暂的事件发生吗? 在过流事件期间、器件的过流保护和保险丝应该已启用。

我怀疑 SHx 引脚上的高电压尖峰也可能导致损坏。 此器件为 80V 直流高电平。  预期的电压范围为 48V、因为绝对最大值允许出现高达 48V 标称电压两倍的瞬态尖峰。

我建议在较低的漏极电压下运行。

谢谢、

Joseph

您好、Joseph：

这是 DRV8353RS-EVM、额定电压为 95vdc 15A、用户手册状态为连接 95 伏直流电源。 这些 NexFET 具有 100 伏击穿电压、绝对击穿电压相对于 25°C 处 12V 直流时的 Qg 电荷。 所有 NFET 上的最大击穿电压都高于建议的额定工作电压。  

3.1 硬件设置：运行电机控制所需的硬件为 ISO-F28027F 开发套件、DRV8353Rx EVM、Mini-USB 电缆和具有 9VDC 至 95VDC 直流输出的电源。 按照以下步骤启动 DRV8353Rx-EVM： SLVUB79A–2018 年 8 月–2018 年 11 月修订

在过流事件期间、我们器件的过流保护和保险丝应该已启用。

您是否同意 30 安培的保险丝保护过度、应该是 20 安培的快速熔断型、并在包装中提供替换保险丝？ 如果额定电流为 15A、30 安培保险丝如何保护此 EVM 上的任何硅器件？  

 更大的问题是、为什么 nFault 引脚 DRV8353RS 绝不会按编程的方式触发为低电平？ 这表明不会通过简单地在 SDI 输入端写入命令而对其进行编程、也不会在写入后通过原始读取验证寄存器。 DRV8353s.c 器件驱动程序假定寄存器设置了正确的字和位！ TI 工程师应使用 while 循环重写这些 SPI 栅极驱动器、以确保寄存器得到适当的编程。  

我们报告称、无论器件驱动程序代码单次写入命令向寄存器发送多少次、设置的 REG 0x02h 惯性滑行位对将 MOSFET 置于高阻抗状态没有影响。

为什么 nFault 引脚不能保护 OVC 情况？ C 代码 EPWM Set nFault (hal.c) 编码为通过 GPIO TZ-1 输入设置跳闸。 如果 nFault 引脚在 OVC 周期内从未触发为低电平、则 NexFET 将按原样被损坏。

我们无法使用 EVM GUI、因为 SCIB 用于 LCD 电机控制、似乎它使用相同的损坏的器件驱动程序 drv8353s.c 来对控制寄存器进行编程？  我们看到 DRV8320RS-EVM 和 GUI 控制 SDK 也存在相同的问题、无法对 SPI 寄存器进行响应。 UMCSDK 中的 SPI 代码示例可能是基本的、需要在写入位拆裂后进行容错原始读取。  当我们将 RAW 添加到 SPI WRITE 所有控制寄存器时、SDO 移位数据并不总是固件作为控制命令发送的数据！ 尽管这不是每个寄存器中的 while 循环、但结果充其量只是一个（位）令人费解、因此我们将代码放回盲目写入 drv8353rs 控制寄存器。

显然、信任缺席的 TI 工程师为该 EVM 编写了正确的 SPI 代码是错误的、应在实验室环境中对其进行重新评估。   

示例位将 REG 0x02 分组在循环中、它是否能够确保对寄存器进行编程？

void DRV8353_writeData(DRV8353_Handle handle, DRV8353_VARS_t *drv8353Vars)
{
    volatile DRV8353_Address_e drvRegAddr;
    volatile uint16_t drvWDataNew;
    volatile uint16_t drvRDataNew;

    if(drv8353Vars->writeCmd)
    {
      while(drvWDataNew != drvRDataNew)
      {
        DEVICE_DELAY_US(2000);//2ms
        // Write Control Register 2
        drvRegAddr = DRV8353_ADDRESS_CONTROL_2;
        drvWDataNew = drv8353Vars->ctrlReg02.all & DRV8353_DATA_MASK;
        DRV8353_writeSPI(handle, drvRegAddr, drvWDataNew);
        DEVICE_DELAY_US(2000); 
        // Read registers for default values
        // Read Status Register 2
        drvRegAddr = DRV8353_ADDRESS_STATUS_2;
        drvRDataNew = DRV8353_readSPI(handle, drvRegAddr);
        drv8353Vars->statReg02.all  = drvRDataNew;
       
      }

同样、EVM 的 J5 输入完全短路！    

您好：

我不认为器件内部的保险丝和过流保护都会失败的原因。 经验证、这两种方法均可正常工作。 这是一款颇受欢迎的器件、已由 TI 和许多其他客户进行评估、获得了工作保护功能。

损坏原因可能是电压高于绝对最大值 这是一个很常见的损坏源、在如此高的电源电压值下、在高于器件规格允许的最大值的制动条件下、几乎可以肯定地看到瞬态尖峰或电源泵回。  

同样、这也是我们器件最常见的损坏原因。 BLDC 系统中可能由于多种原因而发生电压尖峰、这可能是您在此处看到的问题所导致的。

谢谢、

Joseph

在制动条件高于器件规格允许的最大值的情况下。  [/报价]

您好、Joseph：

 我们不使用制动、这种损坏发生在 eSMO 加速低通滤波器 PLL 崩溃期间！ 8353 寄存器未被器件驱动程序代码编程、并且从默认 50ns 死区发生了击穿。 调试表达式在“Expressions"窗口“窗口中显示强制 REG 值并不意味着 8353 实际上设置了控制位！ 很明显、在没有对要写入的每个寄存器进行读取验证的情况下、8353 控制寄存器并不总是通过强制写入进行设置。 请为该 DRV8353RS-EVM 保修、让我们协同工作来解决这些问题。 否则、在任何生产系统中使用这些栅极驱动器都是徒劳的、并且使用了简单的代码逻辑。这再次假设需要对控制寄存器进行编程、此时实际上它们并不总是被编程、并且无法响应单个寄存器写入滑行位绝不会强制栅极驱动进入高阻抗状态。

 MCU 运行 120MHz SYSCLK、即使在寄存器写入之间增加了延迟周期、写入后读取通常会在 1 秒轮询写入中返回已改编的数据、而没有循环验证写入正确的数据。 我们相信、采用 UMCSDK v5.03 封装的 REX 下载的 8353 器件驱动程序可以像具有 x49c LaunchPad 的 drv8320rs 一样工作、并且同一 nFault 引脚未能触发 TZ1 或 OVC、从而保护 NexFET。 还注意到、SDK v4.02 GUI 并不总是写入 drv8320rs SPI 寄存器、当读回的值与发送的值不同时、我们使用了默认值。   

这不是 BLDC 它是 SPM 电机和提供 80Vdc NexFET 运行非常安静,几乎没有低于接地关断热修复或打开高于电源的环尖峰除了它不是第一次电机运行。

主要问题是 nFault 和 OVC 无法正常工作、在电机运行超过 20 个小时、进行 24V 直流或 80V 直流电源测试后始终不会触发单个故障。 另一个 问题是 LaunchXL-39c PZ 器件在 DCA1 DCB1 标志中有 ePWM 勘误表、而 C2000ware TZOST 器件驱动程序调用未清除。 我们从 TI store 购买了两个 LaunchPad、这两个 LaunchPad 都有 CMPSS1 滤波锁存标志并不总是在 POR 或单次写入时清除、而是清除 LATCHSTS 标志。

我们最终切换到 CMPSS4、并使用导线连接的直流逆变器 160V 直流电源、以避免反相 DACVALL 滤波锁存器在远低于设定值的情况下永久跳变。    

您好：

关于更换主板、这不是我们通常的政策、但我会看到我能做什么。  请联系您的现场 (FAE) 联系人、让他们在内部联系我们、了解我们是否可以运送替换产品。  

不过、我很好奇为什么 nFAULT 在您的测试期间不会跳闸。 在进行长达一小时的运行测试之前、您是否通过 SPI 禁用了任何保护功能？ 如果使用更大的死区时间值、是否不会发生击穿情况？

谢谢、

Joseph

请联系您的现场 (FAE) 联系人、让他们在内部联系我们、了解我们是否可以运送替换产品。  

您好、Joseph：

感谢您为 EVM 保修所做的一切、因为要将短接的 NexFET 从 PCB 上拉出需要做一些精密工作。

我们于 2025 年 12 月从 TI store 购买了 EVM。 此处是询问客户服务何时发货的链接。 原始 TI store 订单中缺少实际 TI store 订单历史记录、由于某种原因、他们会删除历史记录。

案例 TT 表 — 客户支持

您是否在一小时内通过 SPI 禁用了任何保护功能

奇怪的是、CMPSS1 在配置两种方式中都显示了恒定的锁存或滤波状态事件、但 DCA1/B1_EVENTS 不会通过组合跳闸区 TZ7 受到影响、并且将每个 CMPSS 隔离到特定的 TZ-7、8、9 没有任何帮助。 对于我们的定制直流逆变器、禁用 CMPSS1 并在后来使用 CMPSS2 确定 DACH/L 滤波器设置导致恒定滤波器锁存状态 CMPSS-2、3、4、而不是在增大它们之后。

//配置数字滤波器。 在本示例中为最大检测值
//用于时钟预分频、样本窗口大小、
//预分频：样本之间的时钟<1024、样本窗口：不>32、
//阈值：<采样窗口/2、但 1<比滤波器阈值。

CMPSS_configFilterHigh (obj->cmpssHandle[cnT]、36、35、17)；//默认值 32、32、30

/*延迟 10us */
DEVICE_DELAY_US (10)；
CMPSS_configFilterLow (obj->cmpssHandle[cnT]、36、35、17)；//默认值 32、32、30

不过、我很好奇为什么 nFAULT 在您的测试期间不会跳闸

 然而、 CMPSS 跳闸或 nFault 引脚将防止击穿事件。 当 eSMO 低通 PLL 滤波器组 200Hz 在较高 80VDC 下发生故障时、显然会发生击穿、而滑动观测器在编写了精细的 24VDC 电源时发生崩溃。 我怀疑 100ns 死区设置实际上是 50ns 的默认值、而不是 100ns、并且 hal.c 设置为 1ns 死区直通、以便 drv8353 死区控制。 即使电势在碰撞中的峰值大于 100Vdc、8353 也应该更快、并且在漏极电压尖峰时进入高阻抗状态。 这应该保护 NeFET 以应对 OVV 事件、因为保护二极管通常具有更大的击穿电压、以便从电机续流 EMF。

 此外、怀疑 3 倍分流电流放大器增益未设置为 10V/V、实际上默认为 5V/V CMPSSx 是否可以在如此低的增益下检测到 OVC 事件、不是！

当 8353 动态扩展 DB 控制窗口时、我们不需要将 ePWM 死区红色/馈电设置为 100ns？ 当 8353 处理此时序时、添加任何 ePWM 死区的要点是什么？

 即使将 SPI 驱动程序代码修改为 1 秒、所有寄存器 OBO（逐个）通常、8353 中移出的值都是默认值、只有在这时 nFault LED 才会随机闪烁。 3 个半桥的 8353 OVC 检测由寄存器值配置、我担心它们不是大多数时候被设置。 当电机控制状态改变时、以下代码监听 1 秒 SPI 写入循环停止。 任何人都会相信表达式窗口寄存器显示的信息、尽管这只是发送到 8353 的内容、而不是实际设置的位。   

#elif defined(_F28003x) || defined(_F28004x)
        /* One second timer for drv8353rs module registers */
        if(HAL_getCPUTimerStatus(halHandle_M1, HAL_CPU_TIMER1) &&
                            (motorVars_M1.motorState == MOTOR_STOP_IDLE) ||
                               (motorVars_M1.motorState == MOTOR_FAULT_STOP))
        {
             /* clear overflow flag */
             HAL_clearCPUTimerFlag(halHandle_M1, HAL_CPU_TIMER1);
             //
             CPUTimer_reloadTimerCounter(HAL_CPU_TIMER1);

             //
             drvicVars_M1.ctrlReg03.bit.IDRIVEP_HS = DRV8353_ISOUR_HS_0P150_A; //820mA DRV8353_ISOUR_HS_0P820_A
             drvicVars_M1.ctrlReg03.bit.IDRIVEN_HS = DRV8353_ISINK_HS_1P100_A; //640mA DRV8353_ISINK_HS_1P640_A

             drvicVars_M1.ctrlReg04.bit.IDRIVEP_LS = DRV8353_ISOUR_LS_0P150_A; //820mA DRV8353_ISOUR_LS_0P820_A
             drvicVars_M1.ctrlReg04.bit.IDRIVEN_LS = DRV8353_ISINK_LS_0P600_A; //640mA DRV8353_ISINK_LS_1P640_A

             drvicVars_M1.ctrlReg05.bit.VDS_LVL = DRV8353_VDS_LEVEL_1P500_V;
             drvicVars_M1.ctrlReg05.bit.OCP_MODE = DRV8353_LATCHED_SHUTDOWN;
             drvicVars_M1.ctrlReg05.bit.DEAD_TIME = DRV8353_DEADTIME_100_NS;

             drvicVars_M1.ctrlReg06.bit.CSA_GAIN = DRV8353_Gain_10VpV;
             drvicVars_M1.ctrlReg06.bit.LS_REF = false;
             drvicVars_M1.ctrlReg06.bit.VREF_DIV = true;
             drvicVars_M1.ctrlReg06.bit.CSA_FET = false;
             drvicVars_M1.ctrlReg02.bit.OCP_ACT = true; // All NEXFets shut down in OVC condition

             //
             //drvicVars_M1.ctrlReg02.bit.CLR_FLT = true;
             //
             drvicVars_M1.ctrlReg02.bit.COAST = false;

             drvicVars_M1.writeCmd = 1;
             HAL_writeDRVData(motorHandle_M1->halMtrHandle, &drvicVars_M1);

        }
#endif

您好：

1.请 发送电子邮件给您指定的现场联系人以了解更换事宜。 这将是第一步。 然后他们可以联系我们,我可以处理后端

2.至于问题本身,您能提供 SPI 读/写波形吗? 但在波形中注意器件是否实际获取了您写入的值会有所帮助。 我仍然认为这是与软件相关的、而不是 DRV8353 器件本身

谢谢

Joseph

您好、Joseph：

请 通过电子邮件向指定的现场联系人发送有关更换的信息。 这将是第一步。 然后他们可以联系我们、我可以处理后端。

过去这种情况是由论坛工程师处理的。 我不确定您也指的是谁。

在波形中说明设备是否实际获取了您写入的值会很有帮助。

考虑到 drv8353-EVM 是 DOA、这会很困难。 线程中显示的 CCS 调试报告、但需要一个视频来显示发送的内容、这并不是即使在几个周期后以任何 SPI 数据速度返回的内容。 在 hal.c 中将 x39c SPI 配置为 30 或 60MHz 分频 SYSCLK。

同样,示例控制寄存器驱动程序代码是不值得信任的,因为它的设计只能在没有验证的情况下写入,就像信任一个孩子用锋利的刀。 它还根据数据表中 的高电平有效使 EN 位反转。 只需报告所找到的内容、TI 专家就可以确定如何修复驱动程序代码！

nSCS 逻辑正确、但 TI 有人混淆了这两个引脚！

至于代码、回答 DRV 问题的应用工程师主要是硬件工程师

您好、Joseph：

我更担心数据表说明 8353 逻辑控制信号操作被正确表达为 RS 版本。

此外、在循环写入读取验证中配置 SDO 移出寄存器后、它们是否应该恢复默认值？ 控制寄存器是 EEROM 单元还是简单的位锁存器？ 不管怎么说,它可能只是一个古怪的 8353 从它的行为方式。

在写入 RS 版本器件上提交新的寄存器值后、我们是否真的要将 nSCS 引脚提高为高电平？ 我根本无法使其正常工作、实际上在 1 秒循环原始代码中导致了更多写入错误。 我放弃了尝试生,只是在空闲时间敲他们。   

感谢所有的调查帮助,它也可以帮助他人 (:-)。

您好、Joseph：

我给你留下了一条关于这个问题的私人消息。 SPIA 和 SCIA LaunchXL-x39c MCU with PZ Silicon 似乎存在未知问题。 这就是我们看到通过 RXFIFO 返回奇数数据的原因。 请记住、当 RX 接收寄存器中存在数据且溢出标志保持清除且 FIFO 中断标志保持设置状态时、CCS 调试 SPIA RXFIFO 未将 RXRDY 标志置为有效。 对我来说、SPIA 配置似乎正常、是否应该与 SPIA 或 SPIB 一起正常工作？   

e2e.ti.com/.../SPIA-Configuration.txt 

您好：

感谢您的更新、我也看到了您的消息。 我正在处理货件。

您是否让 MCU 团队知道了这个问题？  

再次感谢、

Joseph

您是否让 MCU 团队知道了这个问题？  [/报价]

是的、有一个关于该问题的公开论坛帖子、我错误地将其作为 SPIA 发布、并在更改为 SCIA 后。 然而、如前所述、在我看来、CCS 调试中的 SPIA FIFO 原始控制字（如上所述）在当前存在奇数问题的迹象。 我没有像 SCI 外设那样多使用 SPI、并且混淆了两者、因为它们在我看来听起来是一样的。   

供参考：  e2e.ti.com/.../launchxl-f280039c-spia-enhanced-rxfifo-rxbuff-reads-do-not-pop-the-fifo