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.
我尝试了用 C 手动编程、并按照数据表中的标准编程顺序使用 I2C 对 CDCE6214进行编程、但看到 CRC 未成功更新为"R10":nvmscrc。
我尝试使用 TICS Pro v1.7.5.7通过两种方法进行编程:"直接 EEPROM 访问"和"寄存器内容传输"、但我看到 CRC 也没有成功更新到"R10"。
这是我要发送至 burne2e.ti.com/.../HexRegisterValues_5F00_dp_5F00_good.txt 的寄存器映射
以下是刻录过程:
最后、我查看了"原始寄存器"工具页面:R14 = R9 = 0xA95B,但 R10 = 0xE20F。 我预计 R10应与 R9相同。 因此、我检查了 R7 = 0xC2D、Bit5 (CRC 错误)= 1、这意味着发生 CRC 错误!
我再次从2.a 尝试上述序列到2.c、然后检查 R10=0xA95B、它更新了!
我的问题是:
Yang、
执行这些步骤后、执行下电上电。 完成此操作后、读回所有寄存器。 这些寄存器是否仍然与编程之前相同、或者这些值是否经过更新? 是否更新了 CRC 结果?
谢谢。
卡德姆
大家好、Kadeem:
我在首次烧写实验后尝试重启 CDCE6214。 然后、我看到 R10已成功更新! 这是一个很好的试验,但它可能不能解决我的问题。
实际上、如果可能有其他解决方案、我们不希望在刻录 CDCE6214时进行下电上电。
我希望在烧写流程后通过检查 R10=R9来检查 R10是否已使用 R9 CRC 值成功更新。 但现在、我知道在下电上电后 R10=R9。 因此我的问题是、如果我已经检查所有 RW 位是否与我烧录的数据相等、那么在将 CRC 写入 EEPROM 后是否可以跳过校验 R10=R9? 虽然在 CDCE6214正常工作的条件下 CRC 写入流程碰巧失败时、CRC 错误状态可能会出现、但这不会影响 CDCE6214的功能。
我的意思是 CRC 应该 可以在下电上电后更新寄存器中的值。 CRC 写入流程失败(例如 I2C 链路损坏)可能很低、这会在下电上电后导致 CRC 更新失败、从而在我们的产品正常工作时总是引发 CRC 错误。 但实际上、我们的产品中不会使用 CRC 状态、尽管有 CRC 错误位、但 CDCE6214可以正常工作、对吧?
Yang、
CRC 是在器件启动时计算的、因此需要下电上电:请参阅以下内容:
可以通过向 UPDATE_CRC 位 R3[12]写入"1"来触发实时 CRC 重新计算。
谢谢。
卡德姆
您好,Kadeem:
您突出显示的句子是否意味着 R10值是在启动期间计算的? 我认为它指的是 nvmlcrc,而不是 nvmscrc。
Yang、
存储的 CRC (nvmscrc)在器件 EEPROM 编程结束时保存。 启动时 会计算实时 CRC (nvmlcrc)并将其与存储的 CRC 进行比较。
如果在这两个 CRC 不匹配的情况下启动时出现问题、则 NVMCRCERR (R7 [5])将为"1"。
谢谢。
卡德姆
您好,Kadeem:
但为什么我们需要一个粉末循环来检查 R10成功更新? 在执行 CRC 烧写流程后、它应等于 R14和 R9、并且我们希望在执行粉末循环之前直接检查 R10。 但测试结果显示、即使我们使用 TICS Pro 工具、在粉末循环之前也无法更新 R10。
在 EEPROM 刻录之前、R9 (实时 CRC)为0x3303:
EEPROM 刻录后、R9为0xD848:
不 需要下电上电、向 UPDATE_CRC 位发出"1"将更新值:
谢谢。
卡德姆
大家好、Kadeem:
我们来回顾 CRC 校验流程:
因此、如果我们要刻录 CDCE6214、我们应检查 R9:Live CRC 是否已成功更新为 EEPROM。 这意味着我们需要检查 R10是否等于 R9。 如果在我们烧写后 R10不等于 R9、这意味着我们不确定 NVMSCRC 是否已成功更新。
因此我的问题是、如果我们需要一个粉末循环来确认 R10是否等于 R9、这会给我们带来很多麻烦。 如果我们不执行粉末循环、则无法确保 R10成功更新。 那么我们该怎么做呢?
Yang、
启动时、 通过计算 EEPROM 字节0至62的 CRC 来生成 R9 (实时 CRC)的值。 R10 (存储的 CRC)的值从 EEPROM 的字节63加载。 如果这些不匹配、则 NVMCRCERR 位(R7 [5])被设置为"1"。
烧录 EEPROM 后、可设置 UPDATE_CRC 位(R3[12])以触发实时 CRC 的重新计算 不带 要求下电上电。
谢谢。
卡德姆
您好,Kadeem:
您的意思是、如果我们通过设置该位来执行 UPDATE_CRC、以触发实时 CRC 的重新计算、则 TI 会确认实时 CRC 将成功更新为 EEPROM? 通过测试、我们在执行重新计算后没有看到 R10立即更新。
Yang、
在我现在放在工作台上的部分、如果我在 UPDATE_CRC 设置为"1"后读取 nvmlcrc、我得到的值为41350。 如果我对 EEPROM 进行重新编程、在不进行下电上电的情况下、仅再次更新 CRC、我会看到7677。 如果我下电上电并将 UPDATE_CRC 设置为"1"、仍能获得7677。
如上所示、更新 CRC 不需要执行下电上电。
谢谢。
卡德姆
Hi Kakeem K ö:
41350是要编程为 EEPROM 还是7677的新 CRC? 我没有明白您的观点。 您可以尝试以下序列吗:
您可以 尝试该序列吗? 我一直会在步骤3中进行说明。 R10需要下电上电才能通过该实验更新。
Yang、
我明天会有剩下的结果。
谢谢。
卡德姆
Yang、
初始上电时, nvmscrc 和 nvmlcrc 都读取为0。
将 update_crc 设置为"1"后, nvmscrc 和 nvmlcrc 均读为7677。
我将 R43从81更改为80。 将 update_crc 设置为"1"后, nvmscrc 和 nvmlcrc 均读为7677。 这是合理的、因为 EEPROM 尚未更改。 我通过 TiCS Pro 按钮对 EEPROM 进行编程、且 nvlscrc 为 14660 、但 nvmscrc 为7677、而 nvmcrcerr 为"1"。
下电上电、并读取所有寄存器- nvmscrc 和 nvmlcrc 的读数均为0。 我将 UPDATE_CRC 设置为"1"、nvmscrc 和 nvmlcrc 的读数均为14660。
现在、对于第二个测试、我添加了在读取 R9和 R10之后、在进行下电上电之前更新 CRC 的步骤。
将 UPDATE_CRC 设置为"1"后、 nvmscrc 和 nvmlcrc 均读取为14660。
我将 R43更改为40。 将 UPDATE_CRC 设置为"1"后、 nvmscrc 和 nvmlcrc 均读取为14660。 这是合理的、因为 EEPROM 尚未更改。 我通过 TICS Pro 按钮对 EEPROM 进行编程、 nvmlcrc 为50293、但 nvmscrc 为14660、而 nvmcrcerr 为"1"。
将 update_crc 设置为"1"后, nvmscrc 和 nvmlcrc 均读为50293,且 nvmcrcerr 为"0"。
下电上电、并读取所有寄存器- nvmscrc 和 nvmlcrc 的读数均为0。 我将 UPDATE_CRC 设置为"1"、 nvmscrc 和 nvmlcrc 的读数均为50293。
如第二个测试所示、如果通过将 UPDATE_CRC 设置为"1"来重新计算 CRC、则可以在 nvmlcrc 和 nvmscrc 字段匹配中看到更新的 CRC 值、而无需重新启动电源。
谢谢。
卡德姆
您好,Kadeem:
在您的第一个实验中、这就是我们遇到的执行 UPDATE_crr 会导致 NVMLSCRC 被更新但 NVMSCRC 仍保留旧值、即使我们和您都执行了程序 EEPROM 操作、您仍能获得 NVMLCRC=14660但 NVMSCR=7677。 这是关键问题。 我们无法确定 NVMSCRC 是否在没有任何粉末循环的情况下成功更新。
在第二次测试中、您是指我们需要第二次 CRC 更新步骤而不是下电上电来更新 NVMSCRC 吗?
Yang、
正确。 通过第二次 CRC 更新、您可以看到值已正确更新。
谢谢。
卡德姆