[参考译文] TMS320F280039C：DCAN 引导加载程序问题

尊敬的 Rupesh：

更改时钟源和比特率可能会影响您的 CAN 位时序。 您能否确认 bootloader_can_timing.h 中的 CAN_CALC_bitrate、CALC_CALC_CANCLK 和 CALC_CALC_BITTIME 值正确？

此外、还有几个其他澄清问题：

1. switchToXTAL 何时设置为 0？

2.您认为内核直接从 CCS 加载是什么意思？ 加载它的正常方式是什么？

此致、

Alex

您好 Alex、

以下是基于 10MHz 晶体且适用于 500Kbps 的时序参数

#define CAN_CALC_bitrate 500000U
define CAN_CALC_CANCLK 10000000U
#define CAN_CALC_BITTIME 20U。

1. switchToXTAL 何时设置为 0？

它会传递到 DCAN_Boot (CAN_BOOT_ALT3、0、 1. ) 作为 0 或 1。

2.您认为内核直接从 CCS 加载是什么意思？ 加载它的正常方式是什么？

内核  通过 CCS 加载功能加载到 FLASH_BANK2_SEC8_15：origin = 0x0A8002、length = 0x007FED。

我的意思是、如果内核被加载到设备中、设备将直接 运行内核、而无需先运行主固件。

引导过程成功。 在 这种情况下、主固件没有跳转到存储的内核、而是直接引导到内核的器件

让我 重新表述这两个内核版本的行为、以提高清晰度

V1：XTAL 作为 CAN 的源： DCAN_Boot (CAN_BOOT_ALT3、0、 1. )

• 通过允许主固件长分支到内核、然后加载新映像、可以成功实现这一目标。
• 然而、这需要最小的帧延迟 (SLEEP_TIME) 为从编程器端传出的 75ms 延时时间、从而显著提高 时间限制在 8 分钟左右 。
• 如果延迟进一步减少、损坏以及接收到不完整的数据、CAN 无法接收正确的数据

V2：不切换到 XTAL： DCAN_Boot (CAN_BOOT_ALT3、0、 0 )

• 从主 FW 长分支到该内核：内核卡在 DCAN_readMessage () 上
• 但是、如果使用此内核直接将器件置于调试/独立模式（不需要 LB 形式的主 FW）
  • 这样便可以成功加载新的固件 最小帧延迟 10ms
    

这两种情况下、所有时序参数以及其他配置都是相同的。

此致、

Rupeh

尊敬的 Rupesh：

对此处延迟的回复表示歉意。

帮助我了解您的 V1 要点 2 — 要求编程人员侧的最小帧延迟为 75ms。

什么定义了这一要求？

此外、要点 3 — 如果延迟进一步减少，CAN 无法接收正确数据。

这是如何测试的？

我使用下面随附的 CAN 位计时计算器进行了快速分析、以便进一步分析。

/cfs-file/__key/communityserver-discussions-components-files/171/Copy-of-CAN-Bit-Timing-Calculator.xls

这表示位时间 (Tq) 为 10（而响应中显示的时间为 20）。 您能否根据计算器确认针对预期 CAN 总线通信的时序参数正确？

此致、

Zackary Fleenor

尊敬的 Zacakary：

感谢您的回复,希望离线解决此问题,以便更快地解决问题。

我已经为此向您发送了一封邮件。

感谢您的理解！