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.

[参考译文] LP-MSPM0L1306:BSL 独立验证:CRC 不匹配

Guru**** 2391415 points
Other Parts Discussed in Thread: MSPM0L1306, LP-MSPM0L1306

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1474730/lp-mspm0l1306-bsl-standalone-verification-crc-mismatch

器件型号:LP-MSPM0L1306
主题中讨论的其他器件:MSPM0L1306

工具与软件:

我将 为 MSPM0L1306编写主机侧(Linux) I2C BSL 闪存器。 我可以通过 GPIO 调用序列进入 BSL 模式、连接、批量擦除和将数据刷写到器件中。 但是、独立验证无法正常工作。 我使用的 CRC 算法与计算 BSL 消息的校验和相同、用于计算我尝试验证的数据块上的预期 CRC。 但是、从"独立验证"命令返回的 CRC 与我正在计算的 CRC 不匹配。 下面是我用来向 BSL 发送独立验证消息的函数。 BSL_CRC32是我必须在本地生成 CRC32的函数。

bool bsl_verify_simple (uint32_t addr、uint32_t len_data){ 

uint32_t CRC32;

bsl_txbuf[0]= 0x80//packet_header

bsl_txbuf[1]= 9//CMD_BYTE (1)+ Addrs_bytes (4)+ verify_bytes (4)

bsl_txbuf[2]= 0

bsl_txbuf[3]= 0x26//cmd_verify

*(uint32_t *)\bsl_txbuf[4]= addr;//HDR_LEN_CMD_bytes (4)

*(uint32_t *)\bsl_txbuf[8]= len_data;//HDR_LEN_CMD_bytes (4)+ Addrs_bytes (4)

CRC32 = BSL_CRC32 (&bsl_txbuf[3]9);//CMD_BYTE (1)+ Addrs_bytes (4)+ verify_bytes (4)

*(uint32_t *)\bsl_txbuf[12]= CRC32;//HDR_LEN_CMD_BYTES (4)+ Addrs_bytes (4)+ verify_bytes (4)

uint8_t tx_len = 16//HDR_LEN_CMD_bytes (4)+ Addrs_bytes (4)+ verify_bytes (4)+ CRC_Bytes (4)



如果(i2c_write (bsl_txbuf、tx_len))返回 false


uint8_t rx_len = 13// ACK_byte (1)+ HDR_LEN_CMD_bytes (4)+ verify_bytes (4)+ crc_Bytes (4)

如果(i2c_read (bsl_rxbuf、rx_len))返回 false



//检查确认

如果(bsl_rxbuf[0]!= BSL_ACK_OK)返回 FALSE

返回 true

}

int main(){ 

//验证空白闪存以测试 CRC
如果(bsl_verify (01024))、请转到 err;

const uint8_t TEST_DATA_EMPTY[1024]=0x00};
BSL_CRC32 (TEST_DATA_EMPTY、array_LEN (TEST_DATA_EMPTY));
}

BSL 正在接受并处理该消息(返回 ACK 以及正确响应以表明这是一个独立验证响应)、但结果不匹配。 我还尝试了与长度为1024的数组(0xFF)进行比较、但 CRC 仍然不匹配。 下面是从上面构建的原始缓冲区、随响应一起发送到器件。

BSL_VERIFY (已发送): 

0x80 0x09 0x00 0x26 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00 0xa4 0xb8 0x14 0xef

bsl_verify (recv):

0x00 0x08 0x05 0x00 0x32 0x0B 0x00 0xc5 0x47 0x3D 0x93 0x08 0x6b

crc_recv:0x47c5000b

crc_calc:0x104a50d1

用于独立验证的 CRC 算法与用于消息校验和验证的 CRC 算法是否不同? 数据表中未提及此内容、通过查看辅助 BSL 示例(表明示例实现应与 ROM BSL 相匹配)、CRC 参数与数据表相同。

与此相关的是、 MSPM0引导加载程序用户指南(slau887)在第 4.3.10节"独立验证"中包含多个错误。 显示的命令结构是响应数据包、而不是命令数据包。 示例命令(主机)指定地址0x20000000和长度0x400。 示例响应(BSL)不是独立验证响应(0x32)、而是一个内核消息响应(0x3B)、消息内容为0x05 (无效存储器范围):

H | LEN |CMD| A A A A | D D D D | CRC | 

80 09 00 26 00 00 20 00 04 00 00 A0 97 D5 2E

做出权衡

BSL:00 08 02 00 3B 05 B7 F6 FE F2 (MSG:无效地址!)
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jay:

    使用高速缓存首次读取地址0x0~0x8处的数据时出现错误。 因此、如果您执行除地址0x0~8之外的 CRC 或第二次执行 CRC 将解决该问题。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢您的响应 Gary。 我重新进行了测试、运行批量擦除并连续3次请求验证(以确保安全)。 我每次都得到相同的响应- 0x47c5000b。

    从地址0xA 而不是0x0开始尝试了相同的操作、得到了相同的结果。 调用独立验证时是否出错?  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    错误是、当您在地址0x0~8读取非0xFFFF 数据时、会得到0xFFFF、因此您使用的空白器件是相同的。 如果使用某些数据不是0x0~8处的0xFFF、则会有所不同。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    如果我将要刷写的应用程序复制到大小为1024的缓冲区(可以是任意值、0x00、0xFF 或两者之间的任何值)、然后刷写并验证 CRC 是否匹配。 但如果 CRC 不匹配、 我在闪存的哪个位置(0x00、0x400等)写入应用程序似乎无关紧要、或者我重新运行独立验证多少次。 这似乎与您描述的行为不符。


    const uint8_t TEST_DATA_EMPTY[0x400]={0x00}; 
    memcpy (TEST_DATA_EMPTY、APP_DATA、array_LEN (APP_DATA));
    如果(!bsl_flash (0x00、TEST_DATA_EMPTY、array_LEN (TEST_DATA_EMPTY)))、请转到 err;
    如果(!bsl_verify_simple (0x00、0x400)) goto err;
    printf ("CRC app + test_data_empty:0x%08x\n"、*(uint32_t *)&bsl_rxbuf[HDR_LEN_CMD_BYTES + CMD_BYTE]);
    BSL_CRC32 (TEST_DATA_EMPTY、array_LEN (TEST_DATA_EMPTY));

    > CRC app + TEST_DATA_EMPTY:0x7df05312
    > crc: 0x7df05312.
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我进行了测试、获得了正确的 CRC 结果、没有问题

    我所做的是使用两个 LP-MSPM0L1306、一个用作 BSL 目标、另一个用作 BSL 主机。

    我按照 MSPM0引导加载程序(BSL)实现的指导连接器件(修订版 C)

    对于主机端的软件、您可以参阅这个  

    e2e.ti.com/.../bsl_5F00_host_5F00_mcu_5F00_to_5F00_mspm0l11xx_5F00_l13xx_5F00_target_5F00_uart_5F00_LP_5F00_MSPM0L1306_5F00_nortos_5F00_ticlang.zip

    您可以看到、我已在代码中添加了一个软件断点、 以及 BSL CRC 命令和一个软件 CRC

    软件 CRC 结果如下

    我从 BSL CRC 中获得的内容与下面的相同

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    谢谢 Gary! 我感谢您的仔细检查。 您是否介意 在对闪存进行编程的位置张贴行? 段大小是多少? 在我的测试中、 如果 段 I 程序 小于1024B、并且我执行 CRC 校验、则它与我的本地 CRC 不匹配。 但是、如果我确保编程至少为1024B (在应用程序后面具有0xFF 的空空间、如用于空白闪存)、则会正确验证此字段。

    例如:

    @0000
    00 00 00 00 00 00 00 00 00 AF 01 00 AF 01 CA CA CA

    会失败、但如果我按如下方式对剩余部分进行填充:

    @0000
    00 00 00 00 00 00 00 00 00 AF 01 00 AF 01 CA CA CA
    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF f
    ...

    这样它至少有1024个字节长、可以通过。 这时、我已经使用了该权变措施、我只想 确认这是预期行为。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
     您是否注意在闪存编程位置张贴行?

    就在这里

    什么是句段大小? [报价]

    您是指固件大小? 如果是、您可以参阅 application_image_uart.h 文件

    为了使它至少具有1024字节的长度、它将通过。

    是的、(针对 CRC)具有需要检查大于1024的区域的限制

    [/quote]