[参考译文] F28M35H52C：IPC 通信停止工作

NIR、

感谢您访问 E2E 论坛。  我将提出一些澄清问题：

您提到使用 IPC 中断已有几年了、您是否意味着特定器件已经运行了一段时间、现在的运行方式不是相同的？  或者、您是说您最近在 FW 的开发/更改过程中遇到了这种行为吗？

我不能想象工作正常的器件是否会突然停止其2个内核之间的通信。  也许、如果其中一个内核在另一个 ISR 中停止运行？  如果是这样、我会认为内部看门狗最终会导致复位。

将从您那里查找有关上述内容的更多信息。

最棒的

Matthew

您好、Mathew、感谢您的回复、  

是的、同一器件工作多年、现在不工作。 我不断进行固件更新、但这个问题很难重现、因此我想了解您是否能帮助我了解导致此问题的原因。

是的、软件一直在运行、只是没有来自 IPC 的中断...

有什么想法？

NIR、

这是一款器件、有点独特、因为硬件和中断中存在 IPC (处理器间通信)、但我也知道 TI RTOS 封装中也称为 IPC 的模块具有类似用途、 但是适用于此器件和具有 M4内核的其他器件的软件库。  您能否评论一下器件硬件或 RTOS 软件库是否存在此问题？  只需确保我在同一页上

最棒的

Matthew

您好、Matthew、

我不使用 RTOS。 我有2个没有 RTOS 的项目(ARM+DSP)。

我遇到的问题是内核间的通信(IPC)。

我 能够重现错误、我可以看到 MtoC Put 缓冲器已满。  

一旦无法发送完整的消息。

我不知道为什么缓冲区保持满并且未被清除...

有什么想法吗？

我添加了返回 STATUS_FAIL 的 IpcPut 函数代码：

无符号短整型
IpcPut (volatile tIpcController *psController，tIpcMessage *psMessage，
无符号短整型 bBlock)
｛
unsigned short writeIndex；
unsigned short readIndex；
无符号短返回状态= STATUS_PASS；

writeIndex =*(psController->pusPutWriteIndex)；
readIndex =*(psController->pusPutReadIndex)；

//等待 Put Buffer 插槽空闲
while (((writeIndex + 1)& MAX_buffer_index)= readIndex)
｛
//如果被指定为“阻塞”函数，并且 Put 缓冲区已满，
//立即返回失败状态。
如果(！bBlock)
｛
返回状态= STATUS_FAIL；  -------------------------------------------------------   代码会出现在此处、因此不再发送消息
中断；
｝

readIndex =*(psController->pusPutReadIndex)；
｝

如果(返回状态！= STATUS_FAIL)
｛
//空闲时，将消息写入 PutBuffer，更新 PutWriteIndex，
//并设置 M3 IPC INT 标志
psController->psPutBuffer[writeIndex]=*psMessage；

writeIndex =(writeIndex + 1)& MAX_buffer_index；
*(psController->pusPutWriteIndex)= writeIndex；

HWREG (MTOCIPC_BASE + IPC_O_MTOCIPCSET)|= psController->ulPutFlag；
｝

返回状态；
｝

有什么想法吗？

谢谢！

您好、Matthew、

我发现 IPC 中断在 IPC 消息的接收端(DSP)停止工作。

中断(标志)未被确认(未被清除)。 我不确定为什么在 ISR 中 清除标志、并且它始终有效。

出于某种原因、有时它不会被清除、因此来自该组的中断会停止工作。  

NIR、

C28x 端有2个 IPC 中断矢量、我有我们提供的示例 ISR 的 C/P、您能否与 ISR 进行比较并注意到任何差异？  这来自我们的示例中名为 ctom_ipcdrivers_c28.c 的文件

如果您可以的话、您也可以用您的代码回复。  假设 M3仍在发送 IPC 消息、我们停止看到任何外设中断的典型原因是重新启用中断和 ACK 位的竞态条件。  如果 ISR 中有大量代码延迟 ACK/重新 启用、则会发生这种情况。  

我们可以尝试将重新启用置于 ISR 的开头、看看这是否修复了问题。

最棒的

Matthew

//*****************************************************************************
// MtoC IPC INT1 Interrupt Handler -
// Handles writes into M3 addresses as a result of read commands to the C28.
//*****************************************************************************
__interrupt void
MtoCIPC1IntHandler (void)
{
    tIpcMessage sMessage;

    // Continue processing messages as long as MtoC GetBuffer1 is full
    while (IpcGet(&g_sIpcController1, &sMessage,
                  DISABLE_BLOCKING) != STATUS_FAIL)
    {
        switch (sMessage.ulcommand)
        {
        case IPC_DATA_WRITE:
            IPCMtoCDataWrite(&sMessage);
            break;
        default:
            ErrorFlag = 1;
            break;
        }
    }

    // Acknowledge IPC INT1 Flag and PIE to receive more interrupts from group
    // 11
    CtoMIpcRegs.MTOCIPCACK.bit.IPC1 = 1;
    PieCtrlRegs.PIEACK.all = PIEACK_GROUP11;
}

//*****************************************************************************
// MtoC IPC INT2 Interrupt Handler -
// Should never reach this ISR. This is an optional placeholder for
// g_sIpcController2.
//*****************************************************************************
__interrupt void
MtoCIPC2IntHandler (void)
{
    // Should never reach here - Placeholder for Debug

    // Acknowledge IPC INT2 Flag and PIE to receive more interrupts from group
    // 11
    CtoMIpcRegs.MTOCIPCACK.bit.IPC2 = 1;
    PieCtrlRegs.PIEACK.all = PIEACK_GROUP11;
}

您好、Matthew、

非常感谢您的帮助。

接收到您发送的 ISR 代码后、我再次查看了我的 ISR 代码、很明显、我正在使用具有嵌套的中断优先级。 我了解这可能是一个问题、并将其删除。 我真的不需要它。 它现在可以连续工作几天。

我之前的代码如下所示：

_interrupt void MtoCIPC1IntHandler (void)
｛
tIpcMessage sMessage；

/*使用此选项修改中断优先级*/
易失性 uint16 TempPIEIER = PieCtrlRegs.PIEIER11.all；

Dint；
IER |= M_INT11；
IER &= MINT11；//设置"全局"优先级
PieCtrlRegs.PIEIER11.all &= MG111；//设置“组”优先级
//PieCtrlRegs.PIEACK.ALL = 0xFFFF；//启用 PIE 中断
CtoMIPCRs.MTOCIPCACk.bit.IPC1 = 1；
PieCtrlRegs.PIEACX.ALL = PIEACK_group11；
_asm (" NOP")；
EINT；

//只要 MtoC GetBuffer1已满，就继续处理消息
while (IpcGet (&g_sIpcController1、&sMessage、
disable_blocking)！= STATUS_FAIL)
｛
交换机(sMessage.ulcommand)
｛
IPC_BLOCK_WRITE 案例：
IPCMtoCBlockWrite (sMessage)；

//我的代码

中断；
IPC_BLOCK_READ 案例：
IPCMtoCBlockRead (sMessage)；
中断；
案例 IPC_SET_BITS：
IPCMtoCSetBits (sMessage)；
中断；
案例 IPC_CLEAR_BITS：
IPCMtoCClearbits(&sMessage);
中断；
默认值：
中断；
｝
｝

//CtoMIPCRs.MTOCIPCACk.bit.IPC1 = 1；
//PieCtrlRegs.PIEACX.ALL = PIEACK_group11；

Dint；
PieCtrlRegs.PIEIER11.all = TempPIEIER；
EINT；
｝

非常感谢您的参与！

我很抱歉。 但现在 ，经过数小时的直日，我 在另一边也有类似的问题。 我停止在 IPC 的 ARM 端获取中断。

我的代码如下所示：

静态空 CtoMIP2IntHandler (空)
｛
tIpcMessage sMessage；

//只要 MtoC GetBuffer2已满，就继续处理消息
while (IpcGet (&g_sIpcController2、&sMessage、
disable_blocking)！= STATUS_FAIL)
｛
交换机(sMessage.ulcommand)
｛
IPC_BLOCK_WRITE 案例：
IPCCtoMBlockWrite (sMessage)；

//我的代码
中断；
IPC_BLOCK_READ 案例：
IPCCtoMBlockRead (sMessage)；
中断；
案例 IPC_SET_BITS_PROTECTED：
IPCCtoMSetBits_protected (sMessage)；//进程
// IPCCtoMReqMemAccess()
//函数
中断；
IPC_CLEAR_BITS_PROTECTED 案例：
IPCCtoMClearbits_protected (&sMessage)；//进程
// IPCCtoMReqMemAccess()
//函数
中断；
默认值：
中断；
｝
｝

//确认 IPC INT2标志
HWREG (MTOCIPC_BASE + IPC_O_CTOMIPACK)|= IPC_CTOMIPACK_IPC2；
｝

有什么想法吗？

您好、Matthew、

非常感谢您的帮助。

接收到您发送的 ISR 代码后、我再次查看了我的 ISR 代码、很明显、我正在使用具有嵌套的中断优先级。 我了解这可能是一个问题、并将其删除。 我真的不需要它。 它现在可以连续工作几天。

我之前的代码如下所示：

__interrupt void MtoCIPC1IntHandler (void)
{
tIpcMessage sMessage;

/* Use this to modify interrupt priority */
volatile Uint16 TempPIEIER = PieCtrlRegs.PIEIER11.all;

DINT;
IER |= M_INT11;
IER &= MINT11; // Set "global" priority
PieCtrlRegs.PIEIER11.all &= MG111; // Set "group" priority
//PieCtrlRegs.PIEACK.all = 0xFFFF; // Enable PIE interrupts
CtoMIpcRegs.MTOCIPCACK.bit.IPC1 = 1;
PieCtrlRegs.PIEACK.all = PIEACK_GROUP11;
__asm(" NOP");
EINT;

// Continue processing messages as long as MtoC GetBuffer1 is full
while (IpcGet (&g_sIpcController1, &sMessage,
DISABLE_BLOCKING)!= STATUS_FAIL)
{
switch (sMessage.ulcommand)
{
case IPC_BLOCK_WRITE:
IPCMtoCBlockWrite(&sMessage);

// my code here


break;
case IPC_BLOCK_READ:
IPCMtoCBlockRead(&sMessage);
break;
case IPC_SET_BITS:
IPCMtoCSetBits(&sMessage);
break;
case IPC_CLEAR_BITS:
IPCMtoCClearBits(&sMessage);
break;
default:
break;
}
}

//CtoMIpcRegs.MTOCIPCACK.bit.IPC1 = 1;
//PieCtrlRegs.PIEACK.all = PIEACK_GROUP11;

DINT;
PieCtrlRegs.PIEIER11.all = TempPIEIER;
EINT;
}

非常感谢您的参与！

我很抱歉。 但现在 ，经过数小时的直日，我  在另一边也有类似的问题。 我停止在 IPC 的 ARM 端获取中断。

我的代码如下所示：

static void CtoMIPC2IntHandler (void)
{
tIpcMessage sMessage;

// Continue processing messages as long as MtoC GetBuffer2 is full
while (IpcGet(&g_sIpcController2, &sMessage,
DISABLE_BLOCKING) != STATUS_FAIL)
{
switch (sMessage.ulcommand)
{
case IPC_BLOCK_WRITE:
IPCCtoMBlockWrite(&sMessage);

// my code here
break;
case IPC_BLOCK_READ:
IPCCtoMBlockRead(&sMessage);
break;
case IPC_SET_BITS_PROTECTED:
IPCCtoMSetBits_Protected(&sMessage); // Processes
// IPCCtoMReqMemAccess()
// function
break;
case IPC_CLEAR_BITS_PROTECTED:
IPCCtoMClearBits_Protected(&sMessage); // Processes
// IPCCtoMReqMemAccess()
// function
break;
default:
break;
}
}


// Acknowledge IPC INT2 Flag
HWREG(MTOCIPC_BASE + IPC_O_CTOMIPCACK) |= IPC_CTOMIPCACK_IPC2;
}

有什么想法  吗？

NIR、

很高兴您能够使 C 侧正常工作、嵌套 ISR 对于系统中的异步类型事件可能具有挑战性。

我不是很熟悉 M3侧的 NVIC 中断控制器、需要在其他一些地方循环查看。  请给我一整天左右的时间、让更多人回复。

最棒的

Matthew

NIR、

我和一位同事说、他建议 ARM NVIC 可以在本地嵌套 ISR、他建议、如果我们在 M3侧看不到 C28x、则应确保它的末尾仍在生成。

最棒的

Matthew

您好、Matthew、

您能否进一步说明您所写的内容？ 我不确定我是否理解了所有内容。

NIR、

Matthew 在7月8日之前不在办公室。 为了重申他的最后一个帖子： 中断优先级的管理似乎是 C28x 端故障中断接收的可疑原因、因为在删除基于软件的中断优先级代码后问题已经解决。 对于 ARM 端、NVIC 使用本机硬件支持来处理中断优先级、因此我们不会期望 ARM 出现同样的问题。

如何实现 Put 缓冲器？ 您是否枚举了不同的 IPC 位置集？ 如果是、多个中断是否指向同一 ISR？

您是否有检测(和处理)中断溢出的机制？ 我认为、C28x 和 ARM 在发生溢出时都容易受到中断触发的影响。 例如、如果两个(或更多) IPC 中断在 CPU 正忙于执行其他任务/ISR 时到达、则 CPU 仅在最终运行 ISR 时才会意识到第一个 IPC 中断。

对于可快速重现的中断问题、您可以在设置 IPC 标志时切换 GPIO、在执行 IPC ISR 时切换第二个 GPIO。 如果在 ISR 执行之前看到两个标志集切换、则会出现溢出情况。

对于您所描述的慢速烧写情况、记录每个 IPC 中断触发器的本地 CPU 计时器计数并使用未使用的邮箱或全局 RAM 传递枚举标识(如1、2、3等)可能是有意义的。 当处理中断并检查枚举间隙时、远程 CPU 可以在调试缓冲区中记录 ID。 当中断无法触发时、CPU 时间戳的缓冲区可以帮助指示 IPC 触发之间是否需要最小延迟阈值。

Tommy