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.
工具与软件:
尊敬的 Expert:
我的客户在 使用 TCAN4550-Q1时遇到了一些问题、请帮助回答、提前感谢
它们在 RX0中放入8字节接收数据包、在 RX1中放入超过8字节的接收数据包、诊断消息为64字节、位于 RX1中。
1.在独木舟上模拟几个8字节的数据包,然后模拟一个帧周期为40ms RX1的长数据包;
2.然后、它们发送和接收 CAN 诊断消息、并发现响应越来越慢、 他们想知道 TCAN4550-Q1为什么会越来越 慢;
3.然后 他们测试发现,如果在这种情况下,40ms 长消息被停止,诊断消息 TCAN4550不再被报告。 恢复长消息的传输是另一个问题、未报告的诊断消息将一起报告
配置空间小于2K、现在配置是在 Rx0和 Rx1中分配多少个数据包。
此致、
插孔
尊敬的 Jack:
我不确定我是否完全理解。
2. 然后、他们发送和接收 CAN 诊断消息、并发现响应越来越慢、 他们想知道 TCAN4550-Q1为何会 越来越慢;[/QUOT]它们的响应会变得越来越慢、这是什么意思? 它们测量的是什么事件之间的关系? 它们是否测量从连接到 TCAN4550的 MCU 写入 TXBAR 寄存器以发送响应的时间以及消息实际在 CAN 总线上传输的时间? 还是在从 CAUKE 传输消息和从 TCAN4550接收到返回到 CAUKE 的响应消息之间?
请澄清并提供具体的时间示例或示波器图等、因为"较慢和较慢"是一个相对术语、我不知道您指的是什么或期望什么。
它们能否隔离 MCU 写入启动响应传输的 TXAN4550中的 TXBAR 寄存器与在 CAN 总线上看到消息之间的间隔时间? 他们发现的延迟可能来自 MCU、而不是 TCAN4550的 CAN 控制器。
3. 然后 他们测试发现、如果在这种情况下40ms 的长消息停止、则不再报告诊断消息 TCAN4550。 恢复长消息的传输是另一个问题、未报告的诊断消息将一起报告我不明白您所说的"40ms 的长消息已停止、诊断消息 TCAN4550已不再报告。" 这是一条消息是否正在传输至 TCAN4550、如果是、为什么停止?
或者这是来自 TCAN4550的响应消息、似乎正在停止、完整的消息无法传输吗? 如果是第二种情况、该消息是否会在一段时间后恢复传输?
如果消息存在传输错误并看起来被中断、这可能指向与时钟相关的问题、并且它们的晶体时钟电路可能需要进行优化。 请参阅 TCAN455x 时钟优化和设计指南应用报告 (链接)了解详情。
配置空间小于2K、现在配置是在 Rx0和 Rx1中分配的数据包数量。他们要尝试存储多少个数据包?
您是否还可以提供 TCAN4550的完整寄存器配置? 让他们回读所有寄存器、并在其配置序列完成后提供最终器件寄存器的列表。 请勿提供固件代码、我只是想验证器件本身的最终寄存器值。
此致、
Jonathan
[/quote]
您好、专家:
我们测量的时间是 Diag 请求消息和 Diag resp 消息之间的独木舟日志时间。 系统上电后、我们开始发现、此时间间隙约为5-10ms、其中包含多个8字节 app msg (cfg 在 RX0中接收)和一个64字节 app msg (cfg 在 RX1上模拟)。 随着时间的推移、时间间隔超过500ms。初步评估显示、接收诊断消息花费了时间。
然后谈到另一个问题,当间隙达到500毫秒,我们推测它可能是在独木舟上模拟的64字节 msg 造成了这种延迟。 因此、我们停止发送此消息、再次测试 Diag 消息、我们发现 TCAN4550根本没有 Diag 消息报告。 然后、我们继续在独木舟上发送64字节 msg、并停止发送 Diag msg、 先前未报告的消息已被报告。
稍后、我将尝试 在 can_init fun 之后获取器件的最终寄存器值。
时序主要是 MCU 和 SPI 时序的函数。 重要的是要确定 MCU 检测 TCAN4550接收到新消息所需的总时间、读取此消息并通过 SPI 对其进行确认、然后将响应消息加载到 TX 缓冲区中、并设置 TXBAR 位以发送它。
如果没有接收到消息、则您正在使用的 SID 和 XID 过滤器可能存在问题、RX FIFO 或缓冲区均已满、导致消息未存储、或者 CAN 总线上可能出现错误。
还请在测试期间监控各种中断、状态和中断寄存器、以查找可能表明缺少消息的原因等的错误或状态位
此致、
Jonathan
Jonathan、您好!
TCAN4550中所有寄存器的值在初始化过程中以及出现问题时都会打印出来。 请检查附件。
此致、
e2e.ti.com/.../6318.log.zip
Kerry
Kerry、您好!
状态寄存器显示 RX FIFO 已满、消息丢失。 这通常意味着您向 TCAN4550发送消息的速度快于 MCU 读取和确认 TCAN4550中的 RX 消息的速度、从而为新消息释放该元素。
我通常理解您正在发送特定消息、并正在等待特定响应。 如果 RX FIFO 已满、消息被阻止或覆盖(RX FIFO 0设置为覆盖模式、RX FIFO 1设置为阻塞模式)、则 MCU 将无法相应地读取和响应。
您需要降低向 TCAN4550传输消息的速率、或者提高 MCU 通过 SPI 总线读取和处理消息的速度和效率。
此致、
Jonathan
Jonathan、您好!
感谢您的回答。 现在我们遇到了另一个问题、需要您的帮助。
我们目前正在测试 TCAN 4550的 BUSOFF 函数。 测试要求是 BUS_OFF 快速恢复时间应为30ms、缓慢恢复时间应为200ms。 在实际测试中、我们发现接收到"BO:BUS_OFF 状态已更改"时、延迟约为66ms、导致快速恢复时间为96ms (30ms+66ms)、缓慢的恢复时间为266ms (30ms+66ms)。 我是否可以问、报告 BusOff 的延迟为何为66ms? 注意:进行仿真测试时、如果及时报告 Bus_Off、可以满足30到200ms 的时间要求。
附件包含 BUSOFF 日志和代码的屏幕截图。
e2e.ti.com/.../BusOff-Log.zip
此致、
Kerry
Kerry、您好!
设置 BO 状态和中断位时没有内部延迟。 我们看到的延迟必须来自于系统响应中断条件所需的时间。
我不确定您是如何检测中断条件、但与定期读取中断寄存器的软件中断方法相比、使用硬件中断通常可提供更快的响应速度。 TCAN4550-Q1有三个可用于硬件中断的引脚。 nINT 引脚是全局中断引脚、GPIO1和 GPO2可针对特定的 MCAN 中断位进行配置。
此致、
Jonathan
Jonathan、您好!
我们再次测试了 BusOff 函数、发现调用 Init_can()花费了太多时间、大约为62ms。 Init_can ()函数用于初始化 TCAN4550、并包含以下函数:
TCAN4550_SetConfiguration ();
TCAN4550_Start ();
如果我们在测试期间不调用 Init_cn()、我们将无法在快速恢复后正确发送消息。 是否有任何其他方法可以恢复正常发送消息而不调用 Init_can()?
e2e.ti.com/.../Code-screenshot.zip
此致、
Kerry
Kerry、您好!
Init_can ()函数用于完全配置所有寄存器和 MRAM 元素、这些元素需要大量的 SPI 事务。 仅在器件最初上电后、复位后或器件从睡眠模式唤醒后才需要执行此操作。
器件不会因为总线关闭状态而丢失其寄存器配置、因此除非您在总线关闭恢复序列中重置器件、否则不需要重新初始化所有器件寄存器。
当 REC 或 TEC 错误计数器超过最大限制255时、器件将清除 MCAN 控制寄存器(0x1018[0])中的 INIT 位、以防止器件在 CAN 总线上通信。 这也会将 TCAN4550设回待机模式。 如果将器件重新置于正常模式、器件就会自动将 INIT 位复位为1、从而允许其访问 CAN 总线。 发生这种情况后、器件将开始看到 CAN 消息、并且根据 CAN 协议、错误计数器应该会开始丢失、并且器件将在看到128条消息后完成恢复。 充分减少错误计数器所需的时间将随总线上 CAN 消息的数量而变化。
如果没有完全的器件复位、就无法将错误计数器复位为零、这反过来又需要通过 init_can()函数重新配置器件。
下面是 Bosch 关于 M_CAN 总线关闭恢复处理(链路)的应用手册。
此致、
Jonathan
Jonathan、您好!
BUSOFF 是否支持自恢复功能?
此外、是否支持寄存器的批处理配置?
此致、
Kerry
Kerry、您好!
MCAN 控制器 IP 不会从 BO 状态自恢复、并要求 MCU 通过寄存器栈复位 INIT 位。 因此、一旦 MCU 负责检测 BO 状态并启动恢复。
TCAN4550 SPI 接口使用 SPI 标头字中的长度字节支持多种连续寄存器配置、其中包含第一个寄存器(或 MRAM 存储器位置)的起始地址。 每个寄存器包含单个32位数据"字"、因此单个寄存器写入时会将长度字段设置为"1"、然后32位数据将跟随也是32位的标头字。 这使得单个寄存器写入的总位数为64位。
多个连续寄存器只能用一个32位标头字写入、通过消除每个需要写入的寄存器的标头字来减少通过 SPI 传输的总位数。 数据表图说明了在长度字段设置为"2"的情况下进行2寄存器写入。
通过这种方式、可以实现批处理寄存器配置、并减少 SPI 事务之间过多的标头字和空闲时间、这些事务是由于在写入之间将芯片选择线路拉高然后再次拉低而产生的。
唯一需要考虑的是、写入的数据必须位于连续的寄存器或存储器中。 如果存在不会写入的间隙或寄存器、则您需要停止并开始新的事务。
此致、
Jonathan
Jonathan、您好!
我的客户在提出时遇到了许多问题、我们确实需要您的大力支持来帮助他们、您能否告诉我您的自由时间、也许我们需要安排一个会议来讨论此问题、谢谢!
此致、
插孔
Kerry、您好!
我已经查看了数据日志、初始化寄存器设置看起来正常。 我只看到了一个使用传输延迟补偿的调整、可能需要进行调整。 目前、您似乎以80%的采样点为目标、而 TDCO 值将以 FD 数据位的75%二次采样点为目标。 此外、还需要将"Transmit Delay Compensation Filter"(TDCF)设置为0x0、通常建议将其设置为与 TDCO 值相同的值。
TDCF 值定义了"SSP 位置的最小值"、因此值0x0将防止 TDCO 值设置不同的 SSP、这可能导致位错误。
有关发送延迟补偿的更多信息、请参见 M_CAN 用户手册 (链接)。
但是、更大的问题是寄存器和 MRAM 数据始终返回相同的值"问题发生时"、这是意料之外的情况。 我以前在 TCAN4550中看不到这个特定问题、0x86F12203的值对我也没有意义。 MRAM 值对我也没有任何意义。
出现问题时、您能否验证以下内容:
-以下引脚上的电压电平:VSUP、VIO、VCCOUT、FLTR、RST、 INH
-是否可以使用逻辑分析仪(nCS、SCLK、SDI-MOSI、SDO-MISO)捕获 SPI 信号?
- OSC1/2时钟(西里尔斯塔尔或单端时钟)是否正常工作?
-您是否有多个 TCAN4550器件可用于此测试,如果是,该问题是否会在所有 TCAN4550或单个 TCAN4550器件上发生?
-您是否在使用 TI 开发的 TCAN4550板、如果使用、是哪一个? 或者您是否正在使用您自己设计的电路板、如果是、您可以共享原理图以供审阅?
此致、
Jonathan
Jonathan、您好!
感谢 您的回复!
此致、
插孔
尊敬的 Jack:
如果您要提供任何其他信息、我现在将保持该主题开放。 否则、请告知我们此问题是否已解决或何时解决、可以关闭该主题。
此致、
Jonathan