主题中讨论的其他器件： AM5746
在我们的设计中、我们使用 MSP430F2274器件、我们希望在每次主 CPU (AM5746)启动时对其进行编程。 因此、我们在主 CPU 上运行 MSP430_BSL 应用程序(在 Linux 5.4 OS 下)、我们从 TI 在 slaa760.zip 文件中提供的"SITARA Linux Host for MSP430 UART BSL"文件夹中编译该应用程序。
在"SI塔拉 Linux Host for MSP430 UART BSL"文件夹中、我们使用 UART_BSL_MSP430子文件夹中提供的 BSL 应用文件集来编译 MSP430_BSL 应用。 为了进行开发定制 MSP430_BSL 应用的初始测试、我们使用简单闪烁的 LED MSP430程序。
最初、我们通过 JTAG 编程器将闪烁 LED MSP430程序下载到 MSP430F2274微控制器、从而成功测试了它。
因此、在编译 MSP430_BSL 编程应用程序后、我们会在操作系统启动后手动运行该应用程序、并观察到以下情况：(请参阅 main.c 文件)
- 在尝试读取器件 ID (第198行)时、MSP 器件编程的第一次尝试(第168行)总是失败。
- 此故障会导致再次尝试执行相同的代码(第168行)、同时编程成功！
一个明显的问题是：为什么会发生这种情况？
文件0_BSL_timing_overall.png 包含 BSL 编程所涉及信号的总体时序、并参考以下文件、提供了逻辑分析仪收集的总体时序图的更详细视图：
- 文件：1_detail_bsl-entry_wrt-pwd_def.png
- 文件：2_bsl-entry_wrt-pwd_def_with_delayed_ack.png
- 文件：3_detail_delayed_ack_and_tx_data_block_nack.png
- 文件：4_tx_data_block_nack_rst_new_bsl_entry_with_success_seq.png
Fist 尝试
--------------
信号序列从器件复位(第176行)开始、后跟 BSL 进入序列(第185行)、后跟 MSP430_BSL 应用(MCU_BSL_RX)和 MSP 器件(MCU_BSL_TX)信号之间的标头(80)和 ACK (90)字符交换。 在后面的文本中、该字符的交换标记为同步事件。
有关详细信息、请参阅1_detail_bsl-entry_wrt-pwd_def.png。
然后、MSP430_BSL 应用发送'RX password'命令(第187行)、MSP 器件用 ACK 来响应该命令、但仅在~450ms 的相当长的时间后！？ (请参阅2_BSL-entry_wrt-pwd_def_with _delayed_ack.png)。 随后是同步交换。
然后、MSP430_BSL 应用程序发送'TX 数据块命令'、尝试获取器件 ID。 但是、此时、MSP 器件以 DATA_NACK (A0)进行响应、表示命令执行失败。 有关详细信息、请参阅3_detail_pelayed_ack_and_TX_data_block_nack.png。
由于这个故障、MSP430_BSL 应用随后开始第二次尝试 MSP 器件编程 过程。
第二次尝试
--------------------
有关详细信息、请参阅4_tx_data_block_nack_rst_new_bsl_entry_with_success_seq.png
与第一次尝试一样、生成一个新器件复位、然后是 BSL 进入序列、之后是一个同步事件。
MSP430_BSL 应用再次发送'RX password'命令、但这次 MSP 器件以 ACK 无延迟进行响应、后跟一个与之前相同的同步事件。
然后 MSP430_BSL 应用再次发送'TX 数据块命令'、但这次 MSP 器件通过发送器件 ID 数据做出正确响应！
从那时起、剩余的 BSL 编程序列正确完成、MSP 器件开始正确执行其新下载的程序。
问题：
- 这是正常行为吗？
- 是否可以避免这种行为并仅尝试进行 BSL 编程？
- 获取器件 ID 的目的是什么、因为除了打印之外、器件 ID 在代码中不使用？
