[参考译文] TMS320F280039：HWBIST 和中断

您能否判断在 HWBIST 期间触发 CAN 中断时是否有具体发生？ 您能否在寄存器（在 CAN 和 PIE 中）中看到设置了 CAN 中断标志？

Whitney

在 HWBIST 微测试期间、连接调试器不方便。 因此、在测试期间观察相关的寄存器/变量对我来说并不是很方便。

1) 下面是 用于测试的 50us DMA 控制 ISR 代码。

__interrupt void INT_BswDma_DMA1_ADCACH0_6_ISR(void)
{
    //
    // Save IER register on stack
    //
    volatile uint16_t tempPIEIER = HWREGH(PIECTRL_BASE + PIE_O_IER7);

    //
    // Set the global and group priority to allow CPU interrupts
    // with higher priority
    //
    IER |= M_INT7;
    IER &= MINT7;
    HWREGH(PIECTRL_BASE + PIE_O_IER7) &= MG7_1;

    //
    // Enable Interrupts
    //
    Interrupt_clearACKGroup(0xFFFFU);
    __asm("  NOP");
    EINT;

    //
    // Insert ISR Code here ..
    //
    GvUtility_TestData_U[0].u32data++;
    STL_HWBIST_runMicro();

    //
    // Disable interrupts and restore registers saved:
    //
    DINT;
    HWREGH(PIECTRL_BASE + PIE_O_IER7) = tempPIEIER;
}

）2 μ s 是 CAN 接收中断 ISR 代码。

__interrupt void INT_BswCan_CANA_1_ISR(void)
{
    //
    // Save IER register on stack
    //
    volatile uint16_t tempPIEIER = HWREGH(PIECTRL_BASE + PIE_O_IER9);

    //
    // Set the global and group priority to allow CPU interrupts
    // with higher priority
    //
    IER |= M_INT9;
    IER &= MINT9;
    HWREGH(PIECTRL_BASE + PIE_O_IER9) &= MG9_6;

    //
    // Enable Interrupts
    //
    Interrupt_clearACKGroup(0xFFFFU);
    __asm("  NOP");
    EINT;

    //
    // Insert ISR Code here ..
    //

    BswCan_MsgCallback();

    //
    // Disable interrupts and restore registers saved:
    //
    DINT;
    HWREGH(PIECTRL_BASE + PIE_O_IER9) = tempPIEIER;

    #ifdef TRACE_ISR_ENABLE
        //
        //  Add ISR to Trace
        //
        traceISR[traceISRIndex % TRACE_SIZE] = 0x0906;
        traceISRIndex++;
    #endif
}

3）我做了如下一些测试:

当发生 CAN 通信异常时、PIE_IER9 正常、但 PIE_IFR9 会持续设置。 我怀疑这可能与 CPU 级 IER 寄存器有关。

感谢您的耐心。 您是否能够进行任何其他调试？ 我知道 HWBIST 会使调试具有挑战性。 您是否有一些 IO 可以在 ISR 中切换、或者在运行 HWBIST 之前和之后切换、以尝试弄清行为似乎与中断嵌套相关、或者是否专门在 HWBIST 微运行期间发生中断时发生？ 这可以提示我们可能发生了什么。

我在您的 ISR 中没有看到任何相关信息。 我在想你的评论--“PIE_IER9 是正常的、但 PIE_IFR9 是连续设置的。“ 设置 PIEIFF9 但未触发中断可能是由于在最后一个组 9 中断后未复位 PIEACK 问题引起的、或者 CPU IER 或 INTM 未启用。 当 CPU 从 PIE 中获取 ISR 矢量时、应清除 PIEIFR。

Whitney

对于因春节假期而推迟的回复、我深表歉意。

以下是我至今进行的进一步测试：
1) 在 1ms 任务内调用函数 STL_HWBIST_runMicro 时、不会重现无法进入 CAN 中断的问题。
2) 在 20kHz 控制中断内调用函数 STL_HWBIST_runMicro 时、会发生无法进入 CAN 中断的问题。
3) 根据测试 2、我尝试使用 Interrupt_clearACKGroup (INTERRUPT_ACK_group9) 清除 ACK 标志。 这允许重新进入 CAN 中断、但在运行一段时间后、问题再次出现。
4) 根据测试 2、我尝试使用 Interrupt_enable (INT_CANA1) 启用 IER、但没有产生影响、无法进入 CAN 中断的问题也无法解决。

其他问题：
1) 我们的产品应用是双向直流转换器,需要满足 IEC60730 B 类要求。 您是否建议在 20kHz 控制中断内或在后台慢速任务 (1ms/10ms) 内调用函数 STL_HWBIST_runMicro？
2) 是否需要连续调用函数 STL_HWBIST_runMicro、或者一旦覆盖率测试完成并且返回 STL_HWBIST_BIST_DONE、它是否可以停止？

您能告诉我是否  有关于这个问题的新信息吗？

您是否建议在 20kHz 控制中断内或在后台慢速任务 (1ms/10ms) 内调用函数 STL_HWBIST_runMicro？

我不确定标准是否对此有特定要求、或者您是否需要自行决定系统。 您是否需要重复整套测试的频率？ 请记住、STL_HWBIST_runMicro 正在执行单次微运行、它需要运行 750 次才能达到其最大诊断覆盖率。

2) 是否需要连续调用函数 STL_HWBIST_runMicro、或者一旦覆盖率测试完成且返回 STL_HWBIST_BIST_DONE、是否可以停止该函数？

我想您会希望正常连续运行它、这意味着运行它、直到返回 STL_HWBIST_BIST_DONE、重新初始化它并重复该过程。 但是、CPU 测试的 B 类要求不一定需要 HWBIST。 我们拥有没有 HWBIST 的器件、这些器件通过使用 SDL 的 STL_CPU_REG 模块对 CPU 寄存器执行软件测试来满足 B 类要求、并且有一个额外的 PC 计数器测试、因此您可以考虑将其作为一个定期测试而不是 HWBIST 来执行。

Whitney

1.我们使用的是闭环控制系统,我相信在高速控制中断期间进行调用会更好,原因如下:
1.1) 它可实现更快的故障诊断。
1.2) 由于 HWBIST 需要暂停中断执行、因此在控制中断中执行它可确保稳定的控制频率、而在后台运行它可能会导致控制频率抖动。
我知道相关的参考资料、但 STL_CPU_REG 要求测试 CPU/FPU/VCRC 等 我可以在每次触发中断时执行其中一项诊断。 但是、运行 STL_CPU_REG_checkCPURegisters 所需的时间长于 STL_HWBIST_runMicro 所需的时间。 鉴于中断内的执行时间有限、选择 STL_HWBIST_runMicro 更具优势。

关于该问题、我怀疑它可能与中断嵌套期间清除 PIE 标志有关。 稍后我会有时间进行进一步的测试。 通过与处理有关此主题的初始问题中提到的计时器中断 1/2 进行类比、是否有一个基于代码的特定解决方案允许在控制中断中调用 STL_HWBIST_runMicro、而不会影响其他中断的标志清除？

STL_HWBIST_runMicro 仅与讨论的 CPU 计时器中断直接交互。 HWBIST 硬件在微运行执行时记录中断、并在完成并完成寄存器恢复后重新发出中断。 这就是为什么我希望有一种方法来判断受影响的 CAN 中断是否在中断记录期间发生。 不确定在您的系统中设置一些 GPIO 切换或尝试观察准确的时序的可行性有多大。

在 STL_HWBIST_runMicro () 运行时禁用中断（与 DINT 类似）是否会对行为产生影响？ 你不应该有,但它可能是一个有用的实验尝试。

Whitney

为了简化问题、我基于 LAUNCHXL-F280039C 创建了一个新的工程<e2e.ti.com/.../2134.empty_5F00_driverlib_5F00_project.rar>、并且仅将开发板上的原始芯片 F280039CSPZ 替换为 F280039SPZ、该芯片与我们产品中使用的芯片一致。 所有其他设置均按照原始开发板配置进行保持。

资源概览：
1) 时钟源是芯片的内部时钟、总线频率为 120MHz。
2) CPUTIMER0 中断频率设置为 50µs、用于仿真控制中断、并且未启用中断嵌套。
3) CAN 中断：CAN0 处理 CAN 系统级错误、而 CAN1 管理发送和接收中断。 外部器件发送 ID 为 0x1200 和 DLC 8 的扩展帧、而控制器以 ID 为 0x1300 的扩展帧进行回复。
4) 标记为 LEDFault 的红色 LED 用于指示进入 UserNMIISR、errorNMIISR 或 HWBIST 自检错误。
5) 标有 LEDRUN,的绿色 LED 用于指示系统操作,以 1 秒的频率闪烁。

测试过程：
1) 在不使用 HWBIST 函数的情况下、外部器件每 500ms 发送一个 ID 为 0x1200 的帧、而控制器在接收每一帧后以一个 ID 为 0x1300 的帧进行回复。
2) 启用 HWBIST_Init 后、该行为与步骤 1 中的行为相同。
3) 如果在控制中断期间也启用了 HWBIST _Micro、则外部器件每 500ms 发送一个 ID 为 0x1200 的帧、但控制器回复几个帧、然后停止响应。 同时、未设置 LEDFault、指示未发生 NMI 或 HWBIST 错误。 LEDRun 以正常频率闪烁。
4) 然后、我尝试在控制中断中设置计时器中断标志、并在 while (1) 主循环中调用 HWBIST_Micro。 我测试了 1ms、250us 甚至 50us 的计时器频率、但在所有这些情况下 CAN 通信都没有响应。 我想知道在中断中调用 HWBIST_Micro 函数是否可能导致异常？

谢谢。 我翻过代码、没有看到任何明显的设置问题。 下周、我将尝试查找可用于创建一些 CAN 传输的硬件、看看是否可以在自己的电路板上重现问题。

正如我在上一篇文章中提到的、您是否有办法使用一些引脚切换来捕获 CAN 中断和 HWBIST 微运行的确切时间？ 与在计时器 ISR 中一样、在调用 STL_HWBIST_runMicro 之前切换一个引脚、并在之后切换回此引脚、然后在示波器/逻辑分析仪上查看在微运行期间是否发生中断故障之前的最后一次 CAN 传输。

Whitney

我使用两个 IOS 作为相关指标：
1）Dio_ISR、示波器通道 1、【黄色】
2）Dio_HWBIST、示波器通道 2、【绿色】
CANH 和 CANL 的 3）差分信号、示波器通道 3、【蓝色】

相关的中断代码如下所示：

__interrupt void INT_CtrlTimer_ISR(void)
{
    GPIO_writePin(Dio_ISR, 0);

    static uint16_t TimerCnt1s=0;
    static uint16_t TimerCnt1ms=0;

    TimerCnt1s++;
    if(TimerCnt1s>=20000)
    {
        TimerCnt1s=0;
        OsEmu_BswDio_Flag=1;
    }



    GPIO_writePin(Dio_HWBIST, 0);

    /* Case 1: call BswHWBIST_Inst() in while(1) every 50us */
    //OsEmu_BswHWBIST_Flag=1;
    /* Case 2: call BswHWBIST_Inst() here in the control ISR */
    BswHWBIST_Inst();
    GPIO_writePin(Dio_HWBIST, 1);



    // Acknowledge this interrupt to receive more interrupts from group 1
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP1);
    GPIO_writePin(Dio_ISR, 1);
}

测试 1：HWBIST _Micro 在 while (1) 中每 50us 调用一次、并且 CAN 卡每 500ms 发送一个 CAN 帧并接收一个响应帧。 波形如下图：

测试 2.1：在 50us 中断中立即调用 HWBIST_Micro。 首先为开发板上电、并在 10s 后发送 CAN 帧。 第一次传输时不会接收到响应帧。

测试 2.2：首先开始在 CAN 卡上发送 0x1200 帧、然后给开发板上电。 可以看出、接收到两个响应帧后、无法再恢复。
注意：由于 CAN 卡单独启动时控制器未通电、因此没有响应字段。 因此、启动时的帧间隔不是 500ms。

最后一个发送和响应帧波形如下图

  是否有关于此问题的任何新信息？

感谢您的耐心。 我还无法让硬件运行您的测试用例。

感谢您分享详细的示波器捕获。 遗憾的是、我对 CAN 不够熟悉、无法准确了解中断发生的位置以了解问题是否由 HWBIST 中断记录器引起。 您是否还能够切换 CAN ISR 中的引脚并显示它而不是帧波形？

您在前面的线程中提到过、可以 Interrupt_clearACKGroup() 来获取 CAN 中断以重新发出中断。 至少在我们尝试确定问题的实际原因时、作为一种权变措施、您现在是否能够将其添加到计时器 ISR 中？

Whitney

1 μ s）我也没有开发板；我会尽快找到时间进行相关测试。
2）我认为这个问题可能与 HWBIST 执行期间发生的 CAN 中断无关、因为如果是相关的、当我 在 while (1) 循环中执行每个 50 μs 时、还可能在 HWBIST 执行期间发生 CAN 中断、从而导致后续 CAN 中断异常。
3) 我怀疑它可能与在中断内执行 HWBIST 相关。
4) 我们的产品已经进入小型‑规模生产;测试部门不允许在定期中断中持续清除中断标志。 此外、我们的设计不仅涉及 CAN、还涉及外设和中断等 我需要知道如何在不影响其他模块的情况下安全调用 HWBIST。

我不确定您要我运行的测试是否与下面的说明相符。 此处不使用 ISR 嵌套。 测试环境简介：
-> Dio_isr、示波器通道 1、【黄色】
-> Dio_HWBIST、示波器通道 2、【绿色】
-> Dio_CANISR、示波器通道 3、【蓝色】

1) 50µs 控制中断代码如下。 在中断中、切换 DIO_ISR：

__interrupt void INT_CtrlTimer_ISR(void)
{
    GPIO_writePin(Dio_ISR, 0);

    static uint16_t TimerCnt1s=0;
    static uint16_t TimerCnt1ms=0;

    TimerCnt1s++;
    if(TimerCnt1s>=20000)
    {
        TimerCnt1s=0;
        OsEmu_BswDio_Flag=1;
    }

    /* Case 1: call BswHWBIST_Inst() in while(1) every 50us */
    OsEmu_BswHWBIST_Flag=1;
    /* Case 2: call BswHWBIST_Inst() here in the control ISR */
    //BswHWBIST_Inst();

    // Acknowledge this interrupt to receive more interrupts from group 1
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP1);
    GPIO_writePin(Dio_ISR, 1);
}

案例 1：在 while (1) 中执行 BswHWBIST_Inst ()、每个 50µs 都执行。
案例 2：在 50µs 控制中断中直接执行 BswHWBIST_Inst ()。

2) BswHWBIST_Inst () 函数如下所示,此函数将切换 Dio_HWBIST。

void BswHWBIST_Inst(void)
{
    GPIO_writePin(Dio_HWBIST, 0);
    HWBISTTimes++;
    uint16_t returnVal = 0;

    /* Run a micro-run of HWBIST */
    returnVal = STL_HWBIST_runMicro();

    /* Result Handle */
    if(STL_HWBIST_MACRO_DONE == (returnVal & STL_HWBIST_MACRO_DONE))
    {
        if( (returnVal & ~(STL_HWBIST_BIST_DONE | STL_HWBIST_MACRO_DONE))!= 0 )
        {
            //Fail
            GPIO_writePin(FaultLED_GPIO,0);
        }
        else if( STL_HWBIST_BIST_DONE == (returnVal & STL_HWBIST_BIST_DONE) )   //STL_HWBIST_BIST_DONE
        {
            STL_HWBIST_init(STL_HWBIST_90_LOS);
        }
        else        //STL_HWBIST_MACRO_DONE
        {}
    }
    else
    {
        //Fail
        GPIO_writePin(FaultLED_GPIO,0);
    }

    OsEmu_BswHWBIST_Flag=0;
    GPIO_writePin(Dio_HWBIST, 1);
}

3) CAN 中断函数如下、该函数切换 Dio_CANISR。

__interrupt void INT_BswCan_CANA_1_ISR(void)
{
    static uint32_t status;
    static uint16_t tempBuffer[8]={1,2,3,4,5,6,7,8};
	
	GPIO_writePin(Dio_CANISR, 0);
    status = CAN_getInterruptMessageSource(BswCan_CANA_BASE);
    
	if((status>>0)&0x01)
    {
        tempBuffer[0] = HwBISTTimes;
        CAN_sendMessage(BswCan_CANA_BASE, 2, 8, tempBuffer);
        CAN_clearInterruptStatus(BswCan_CANA_BASE, 1);
    }

    CAN_clearGlobalInterruptStatus(BswCan_CANA_BASE, CAN_GLOBAL_INT_CANINT1);
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP9);
    GPIO_writePin(Dio_CANISR, 1);
}

测试 1：每 100ms 从 PC 发送一次 CAN 消息、该器件将继续响应。

测试 2： 每 100ms 从 PC 发送一次 CAN 消息、在 DSP 复位后、它将对几帧进行响应、然后停止响应。

我设计了一个简化的测试、用 ePWM 周期性计时器中断取代了 CAN 中断。 在 ePWM 中断中、I/O 引脚切换呼吸 LED。
 while(1) 循环中的每个 50µs 调用 HWBIST 不会影响 ePWM 中断的进入。 但是、如果在 50µs 控制中断中直接调用 HWBIST、则在 operation.e2e.ti.com/.../3007.empty_5F00_driverlib_5F00_project.rar 的一小段时间后停止触发 EPWM 中断

感谢您分享屏幕截图和更新的项目。 知道它也可以通过 PWM 中断进行复制、这一点很有用。 这应该比尝试生成 CAN 中断更容易调试。 我希望我明天能够运行您的测试代码、并将使用我观察到的行为更新您。

Whitney

好的、在不考虑中断嵌套的情况下、可以理解的是、如果 CAN 中断在计时器中断后立即发生、则设置 IFR (CAN) 和 IFR（计时器）。 然后、在计时器中断中调用 STL_HWBIST_runMicro。 HWBIST 执行完成并复位后、IFR (CAN) 将自动清除、因此不处理 CAN 中断。

由于我们的产品已进入小规模生产阶段、我们还采用了与中断嵌套相关的设计。 根据您的经验、在 while (1) 中调用 STL_HWBIST_runMicro 是否是不会影响其他中断的最安全解决方案？

while 循环现在可能是最安全的、但我知道是否不可行、因为您希望以多长时间运行测试。 在我上面列出的选项中、#2 可能是我们将实施的选项、作为针对此问题的错误修复、但我认为需要更多测试、以确保我们没有错过任何边缘情况。 如果您尝试、请告诉我们它是如何为您效劳的。

Whitney