[参考译文] CC2642R：当我们尝试在1ms 的任务内进行刷写时出现闪存失败

您好！

"1ms 任务"和"2ms 任务"是什么意思？

在两种情况下(对于两个任务、分别为1ms 和2ms)是否都要刷写相同的固件？

如果你确实获得了 FLASH_FAIL 状态、你能否尝试增加你的任务的周期(例如、如果1ms 任务失败一次、尝试改为等待2ms、然后在任何2ms 的成功加载后恢复为1ms)。

谢谢！
Toby

HI TOBY P (5084795)、
 

感谢您的响应,
 

1ms 任务意味着它是一个运行程序、每1毫秒调度一次、2毫秒调度 一次(计划每2毫秒运行一次)
 

我能知道 FW 是什么意思吗? (我的理解是相同的二进制)
 

如果我的理解是正确的,那么是的,我试图闪存相同的二进制两种情况。

我有一个问题、如果我们得到 FLASH_FAIL、那么我们需要再次从 ping 开始、或者我们需要再次重新发送同一个数据包？

Unknown 说：

我能知道 FW 的含义是什么吗? (我的理解是相同的二进制)

是的、"FW"是指"固件"、基本上与"二进制"相同。

Unknown 说：

1ms 任务意味着它是一个运行程序、计划每1毫秒运行一次、同样持续2毫秒( 计划每2毫秒运行一次)

感谢您的澄清。 在这种情况下、我的建议保持不变：

[报价 userid="324727" url="~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1404019/cc2642r-getting-flash-fail-when-we-are-trying-to-flash-in-1ms-task/5375562 #5375562"]如果您确实获得了 flash_fail 状态、您能否尝试延长任务的执行时间(例如、如果任务在1ms 任务上失败一次、请尝试等待2ms、然后在成功加载2ms 后恢复为1ms)。

[报价 userid="620258" url="~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1404019/cc2642r-getting-flash-fail-when-we-are-trying-to-flash-in-1ms-task/5376284 #5376284"]

如果我的理解是正确的,那么是的,我试图闪存相同的二进制两种情况。

我有一个问题、如果我们得到 FLASH_FAIL、那么我们需要再次从 ping 开始、或者我们需要再次重新发送同一个数据包？

[报价]

如果得到 FLASH_FAIL、我建议发送之前的 SEND_DATA。

尊敬的 Toby：

 I1)我要尝试缩短 TI_FLASH 时序、我必须在1ms 内调用 TI_Flashing Runnable。 在1ms 后、我们再次尝试发送相同的失败数据包、但我们获得的返回值与(闪存故障)相同。 我该怎么办？

2)在本例中、我们将 BAUDRATE 设置为 600000U、极性和相位设置为1和1、使用 MSB、我们可以使用以下参数实现的最短时间是多少？

3)如果增加或减少发送给 TI 的0的数量、在任何 CMD 之后、我们将不会收到响应。 对此有什么想法吗？

例如：我要发送 CRC CMD、之后我要发送8个零来获取 TI 的响应。 现在、经过几次失败、我将从 TI 芯片获得正确的 CRC 值。 现在、如果我将8个零点更改为10个零点或12个零点、我们将无法获得 CRC 响应、对此有什么想法吗？  

感谢您分享有关您的调查的更多详细信息。

我将在3个工作日内查看并提供更新。

您能尝试使用较低的数据速率吗？

例如、我们的控制器示例使用1000000。

请尝试使用不同的数据速率、并告诉我们这些速率是否有所改善。

嗨、Toby、对于1000000、 它正在闪烁、但在验证期间我们收到 CRC 不匹配错误。 对于 1050000 FLASH_FAIL、我们将得到。 我需要测试的任何其他值？

 

问题 3的任何更新)如果增加或减少发送给 TI 的零数、在任何 CMD 之后、我们将不会收到响应。 对此有什么想法吗？

尊敬的 ARUL：

托比是一个当之无愧的假期,直到9/9,所以我可以尝试协助,直到他返回。

Unknown 说：

对于1000000、 它正在闪烁、但在验证时出现 CRC 不匹配错误

这是一个改进。  您使用什么引导加载程序软件以及它如何检查 CRC？  即使未经验证、二进制文件是否能够按预期运行和运行？

Unknown 说：

对于 1050000 flash_fail、我们将获得。 我需要测试的任何其他值?[/报价]

从 TRM 的第10.2.2章开始："SSI 接口有一个硬件要求、此要求将 SSI 时钟的最大速率限制为最多为 SSI 模块时钟频率的1-12 (48 MHz / 12 = 4 MHz)。"  因此、6 MHz 是不可接受的、并且1.05 MHz 无法与 SSI 模块时钟进行很好的分频、也会产生问题。

Unknown 说：

如果增加或减少发送给 TI 的零点数、经过任何 CMD 后、我们将无法收到回复。 对此有什么想法吗？

您需要使用正确的 COMMAND_DOWNLOAD_CRC 数据包格式来接收 ACK。  TRM 的第10章(以及其他引导加载程序详细信息)对此进行了详细介绍。

此致、
Ryan

[/quote]

您好、Ryan、

感谢您的响应。

 Ryan 说： 这是一个改进。 您使用什么引导加载程序软件以及它如何检查 CRC？  即使未经验证、二进制文件是否能够按预期运行和运行？

为了刷写 TI_CHIP、我们将使用后门引导加载程序模式、 由于 expected.it 甚至无法启动、因此二进制文件未在运行。

 Ryan 说：  从 TRM 的第10.2.2章开始："SSI 接口有一个硬件要求、此要求将 SSI 时钟的最大速率限制为最多为 SSI 模块时钟频率的1-12 (48 MHz / 12 = 4 MHz)。"  因此、6 MHz 是不可接受的、并且1.05 MHz 无法与 SSI 模块时钟进行很好的分频、也会产生问题。

为此、我将使用不同的值进行测试。

 Ryan 说：  您需要使用正确的 COMMAND_DOWNLOAD_CRC 数据包格式来接收 ACK。   TRM 的第10章(以及其他引导加载程序详细信息)对此进行了详细介绍。

这不仅仅是关于 Download_CMD、我想说的是在向 TI 发送任何数据包后、为了从 TI 获得响应、我们需要发送零、如果您增大或减小该零、我本身没有得到响应。