工具/软件：
我们发现总线关闭恢复并触发中断、同时 CAN 总线仍然短缺、固件不进行复位或初始化、想知道什么原因吗？
下面是波形、 通道 1 是 CAN-TX、通道 2 是 GPIO、用于指示固件执行 mcan init（从 H 到 L）、通道 3 是 GPIO、以 mcan 中断为单位指示总线关闭状态（可以检查下面的中断代码）
CH-3 为高电平表示总线关闭在开始时设置、然后 CH-2 拉至低电平以执行 mcan init、通道 3 拉至低电平以指示总 线关闭在 2.8ms 后中断时恢复、然后 CAN 总线再次保持短缺、通道 3 在中断时再次拉至高电平以指示总线关闭设置、但是为什么即使 CAN 总线保持短缺、通道 3 也会在 2.8ms 后拉至低电平？
很抱歉、上传波形图、请在下面进行检查、谢谢
您好、Joseph
客户 通过使用 GPIO 添加代码来指示状态、 CH1 为 PSR.BO 值、CH2 为 CCCR.INIT 值、而 CH3 为 CCCR.INIT CLEAR 函数操作。
根据波形、CH1 显示 2.8ms 后总线关闭恢复、CH2 显示 INIT 跟随总线关闭状态立即、但 CH3 未发生 INIT 清除操作、您认为这是否是正常行为？ 产生该波形的原因是什么？
您好、Joseph
感谢您的建议,我们可以理解为什么巴士关闭再次设置,我们混淆了为什么巴士关闭是明确的最后一个。
我们执行如下更多测试、CH1 监测中断中的 PSR.BO 状态、 CH3 监测中断中的 CCCR.INIT 状态。 CH2 在 200us 计时器中断中监测 CCCR.INIT 状态。
从波形可以看出、CH3 与要再次设置 CH1 相同、然后在最后 3ms 后清除、但 CH2 无法捕获 INIT 设置时刻、在设置之后似乎 INIT 应非常快速地清除。 我们无法理解 init 的原因和原因、您能帮助我们理解吗？
您好、Joseph
客户可以将波形捕获为您的建议、CH1 表示总线关闭状态、CH2 表示 INIT 位状态、CH3 表示 MCAN配置 运行时间（GPIO 在 MCAN配置 开始时切换为高电平、在 MCAN配置 结束时切换为低电平）
波形 1 和 2 显示了 初始化设置为-> 100ms ->清除->传输->设置-> 100ms ->清除 ；
波形 3 显示了 INIT 设置-> 100ms ->清除->传输->设置-> 3ms ->清除的异常行为 ；
但是 、MCANConfiguration 运行时间在 3 个波形中约为 380us、500us 或 400us 、MCANConfiguration 确认在异常 情况下不会再次运行。
如果有任何可能的原因、请帮助您仔细检查行为、问题大约需要 2 周时间、客户迫切需要回复 OEM 的答案。
您好、Terry、
我使用客户的其中一个快照注释定时任务+计数器例程的异步性质、以监控并从总线关闭中恢复。 可以清楚地看到、调用 MCANConfiguration 后、将 INIT 位清除需要超过 3ms、如蓝色标记所示。
若要使此方案正常工作、一旦设置 CCCR.INIT、就应立即清除 INIT 位、而不是在 3ms 后生效。 这会使函数 HandleBusoffFastSlowRecovery() 中的内部计数器混乱、因为这是每 1ms 调用一次的。 应对总线关闭位进行轮询、以确保清除该位后才能正常工作。 请参阅随附的片段。 我在第 55 行添加了一个 while 循环。
static void HandleBusoffFastSlowRecovery(void)
{
static UInt8 u8McanBusOffCounter = INITIAL_ZERO;
static UInt8 u8TxMsgNum = INITIAL_ZERO;
static UInt8 u8BusoffToRecoveryFlg = INITIAL_ZERO;
static UInt16 u16McanBusOffRecoveryTime = INITIAL_ZERO;
static UInt16 u16McanBusOffEventStartTime = INITIAL_ZERO;
static UInt8 u8McanBusOffStatus = INITIAL_ZERO;
uint32 u32Temp = 0UL;
if(TRUE == u8BusOffTimer1msFlg)
{
#if 0
u8McanBusOffStatus = ((*(uint32 *)(MCANA_DRIVER_BASE + MCAN_PSR) & 0x80u) >> 7u);
u32Temp = ((*(uint32 *)(MCANA_DRIVER_BASE + MCAN_PSR) & 0x80u) >> 7u);
u8McanBusOffStatus = (Uint8)u32Temp;
#else
u32Temp = (*(uint32 *)(MCANA_DRIVER_BASE + MCAN_PSR) & MCAN_PSR_BO_MASK) & 0xFFU;
u8McanBusOffStatus = (Uint8)u32Temp;
#endif
if(u8McanBusOffStatus == 0x80u)
{
u8BusoffControlMsgFlg = 1u;
/*cancel message transmit request in busoff*/
if(0u != MCAN_getTxBufReqPend(MCANA_DRIVER_BASE))
{
for(u8TxMsgNum = 0u; u8TxMsgNum < (NUM_OF_MSG - 1U); u8TxMsgNum++)
{
MCAN_txBufCancellationReq(MCANA_DRIVER_BASE,u8TxMsgNum);
}
}
u16McanBusOffEventStartTime++;
if(u8McanBusOffCounter >= BUS_OFF_FAST_RECOVERY_COUNTER)
{
u16McanBusOffRecoveryTime = BUS_OFF_SLOW_RECOVERY_TIME; /*busoff slow recovery delay time*/
}
else
{
u16McanBusOffRecoveryTime = BUS_OFF_FAST_RECOVERY_TIME; /*busoff fast recovery delay time*/
}
if(u16McanBusOffEventStartTime > u16McanBusOffRecoveryTime) /*busoff fast recovery attempt counter*/
{
u16McanBusOffEventStartTime = 0u;
/*Once CCCR.INIT has been cleared by the CPU,the device will then wait for 129 occurrences of Bus Idle (129 *
11 consecutive recessive bits) before resuming normal operation*/ /*129 * 11 * 1 / 500k = 2.8ms*/
MCANConfiguration();
while(*(uint32 *)(MCANA_DRIVER_BASE + MCAN_PSR) & MCAN_PSR_BO_MASK);
u8BusoffToRecoveryFlg = 1u;
if(u8McanBusOffCounter < BUS_OFF_COUNTER_LIMIT)
{
u8McanBusOffCounter++;
}
}
}
else
{
/* Each Tx Buffer has its own Transmission Occurred bit. The bits are set when the corresponding TXBRP bit is cleared after a successful transmission.
The bits are reset when a new transmission is requested by writing a '1' to the corresponding bit of register TXBAR. */
if(MCAN_getTxBufTransmissionStatus(MCANA_DRIVER_BASE) != 0U)
{
u8McanBusOffCounter = 0u;
u16McanBusOffEventStartTime = 0u;
}
}
u8BusOffTimer1msFlg = FALSE;
}
if((1u == u8BusoffToRecoveryFlg) && (0u == u8McanBusOffStatus))
{
u8BusoffControlMsgFlg = 0u;
/*Enable first frame send immediately - 20250620 LiuGaoSong*/
u8FirstMsgSendFlg = TRUE;
u8BusoffToRecoveryFlg = 0u;
}
}
如果此方案有效或说服客户使用中断处理程序来管理 CAN-FD 总线关闭、请使用此方案。 您还可以在网上搜索 CAN-FD 总线关闭处理、其他制造商的所有其他论坛建议通过中断处理程序关闭总线。
此致、
Joseph
您好、Joseph
客户通过以下代码中断更新总线关闭处理程序、您能否帮助审核是否正确？
他们将在第一次 MCAN 中断后立即调用函数来清除总线关闭状态、 还可以处理传输并 在中断中检查 TXBRP 是否清除、但是即使不开始新的传输、有时 MCAN 将在大约 3~4ms 后再次进入总线关闭中断。
我们是否可以再次与您确认是否 仅在设置了 TXBAR 的情况下才会发生新的传输？ 总线关闭应该只发生传输失败？
