[参考译文] MSP432E411Y：通过以太网更新 BSL Scripter 失败会使 MSP432应用程序砖化

尊敬的 Charles：

感谢您的答复并指出帖子中的示例。

该应用程序在我的 TI-RTOS 构建中使用的 release.cfg 文件(tirtos_builds_MSP432E411Y_BGAEVM_release_ccs)包含  以下行：m3Hwi.resetVectorAddress = 0x4000；这会在 Debug/configPkg/下生成一个 linker.文件、末尾具有以下代码：

/*
 * symbolic aliases for static instance objects
 */
xdc_runtime_Startup__EXECFXN__C = 1;
xdc_runtime_Startup__RESETFXN__C = 1;
xdc_rov_runtime_Mon__checksum = 1;
xdc_rov_runtime_Mon__write = 1;


SECTIONS
{
    .bootVecs:  type = DSECT
    .resetVecs: load > 0x4000
    .vecs: load > 0x20000000, type = NOLOAD



    xdc.meta: type = COPY
    xdc.noload: type = COPY
}

在示例  TM4C1294XL_TI_tcpecho_non_zero_reset_vector 和  TM4C1294XL_simple_bootloader 中、看起来引导加载程序具有一个主函数、即将调试输出写入 UART、然后使用一些汇编器代码在 #define APP_RESET_VECTOR_ADDR 0x8100处跳转到应用。  这是否意味着引导加载程序每次启动时都会运行、然后将控制权转移给应用程序？ 那么  应用程序的.cfg 文件中的 m3Hwi.resetVectorAddress = 0x8100；行有什么作用？

我将  针对 MSP432使用 boot_serial_emac_flash 示例。 我曾在电路板复位时认为处理器会直接跳转到0x4000地址、因为我们  在 TI-RTOS build .cfg 文件中使用了行 m3Hwi.resetVectorAddress = 0x4000、这是正确的吗？ 重置评估板时，我没有从引导加载程序中看到任何 BOOTP 消息，表明它正在寻找软件更新。

如果我只加载了  不含应用程序代码的 boot_serial_emac_flash 并重置 MSP432、我确实可以在网络上看到 BOOTP 消息、并可以发送软件更新。

 boot_serial_emac_flash  示例是否有一个 main 函数入口点、可以运行该入口点并将控制传递给应用？ 如果引导加载程序首先运行，它如何决定传输到应用程序而不是发送 BOOTP 消息(如果没有加载应用程序)？

我的应用链接器文件如下所示：

--stack_size=1024   /* C stack is also used for ISR stack */
#define APP_BASE 0x00004000

HEAPSIZE = 0x20000;  /* Size of heap buffer used by HeapMem */

MEMORY
{
    FLASH (RX) : origin = APP_BASE,   length = 0x00100000
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

/* Section allocation in memory */

SECTIONS
{
    .text   :   > FLASH
    .const  :   > FLASH
    .rodata :   > FLASH
    .cinit  :   > FLASH
    .pinit  :   > FLASH
    .init_array : > FLASH

    .TI.ramfunc : {} load=FLASH, run=SRAM, table(BINIT)
    .data   :   > SRAM
    .bss    :   > SRAM
    .sysmem :   > SRAM

    /* Heap buffer used by HeapMem */
    .priheap   : {
        __primary_heap_start__ = .;
        . += HEAPSIZE;
        __primary_heap_end__ = .;
    } > SRAM align 8

    .stack  :   > SRAM (HIGH)
}

引导加载程序链接器文件：

--retain=Vectors

/* The following command line options are set as part of the CCS project.    */
/* If you are building using the command line, or for some reason want to    */
/* define them here, you can uncomment and modify these lines as needed.     */
/* If you are using CCS for building, it is probably better to make any such */
/* modifications in your CCS project and leave this file alone.              */
/*                                                                           */
/* --heap_size=0                                                             */
/* --stack_size=256                                                          */
/* --library=rtsv7M3_T_le_eabi.lib                                           */

/* System memory map */

MEMORY
{
    FLASH (RX) : origin = 0x00000000, length = 0x00010000
    SRAM (RWX) : origin = 0x20000000, length = 0x00010000
}

/* Section allocation in memory */

SECTIONS
{
    GROUP
    {
        .intvecs
        .text
        .const
        .data
    } load = FLASH, run = 0x20000000, LOAD_START(init_load), RUN_START(init_run), SIZE(init_size)

    GROUP
    {
        .bss
        .stack
    } run = SRAM, RUN_START(bss_run), RUN_END(bss_end), SIZE(bss_size), RUN_END(__STACK_TOP)

您好！

Unknown 说：

添加  上面的 m3HW.resetVectorAddress = 0x4000行是否会更改复位矢量并使 MSP432在启动时引导至地址为0x4000的应用程序？ 或者它是否仍会首先引导至闪存地址0x0000处的引导加载程序？

闪存引导加载程序应位于0x0。 复位后、处理器从引导加载程序所在的0x0开始。 如果在0x4000处找到有效的应用程序、则会跳转到该应用程序。

Unknown 说：

在示例  TM4C1294XL_TI_tcpecho_non_zero_reset_vector 和  TM4C1294XL_simple_bootloader 中、似乎引导加载程序具有一个主函数、将调试输出写入 UART、然后使用一些汇编器代码跳转到#ADDR_RESET_APP_0x8100处 的应用。  这是否意味着引导加载程序每次启动时都会运行、然后将控制权转移给应用程序？ 那么、  应用程序的.cfg 文件中的 m3Hwi.resetVectorAddress = 0x8100；行会执行什么操作？

如上所述、闪存引导加载程序首先由处理器运行。 如果0x4000处存在有效应用程序、则它将跳转至0x4000以运行该应用程序。 应用程序运行后、它可以根据触发条件跳回引导加载程序、以强制对应用程序进行更新。 该触发条件可以检测引脚状态变化或检测魔术包。 跳回引导加载程序的方式和时间取决于应用程序。

Unknown 说：

如果我只加载  boot_serial_emac_flash  而没有应用程序代码，并重置 MSP432，则我在网络上确实看到 BOOTP 消息，并且能够发送软件更新。

是的、这是预料之中的。

Unknown 说：

  boot_serial_emac_flash  示例是否有一个运行 main 函数入口点并将控制权转移给应用程序？ 如果引导加载程序首先运行，那么它如何决定传输到应用程序而不是发送 BOOTP 消息(如果没有加载应用程序)？

请参考 C：\ti\simplelink_msp432e4_sdk_4_20_00_12\source\ti\devices\msp432e4\boot_loader\bl_startup_ccs.s 文件。  

尊敬的 Charles：

感谢您的答复。 我可以从 bl_startup_ccs.s 看到、ResetISR 函数(映射到引导加载程序 存储器中的复位矢量)从 bl_check.c 调用 CheckForceUpdate 函数、该函数检查在应用程序存储器0x4000的底部是否有一个看起来像有效堆栈指针和复位矢量的函数。

uint32_t
CheckForceUpdate(void)
{
#ifdef CHECK_CRC
    uint32_t ui32Retcode;
#endif

#ifdef BL_CHECK_UPDATE_FN_HOOK
    //
    // If the update check function is hooked, call the application to determine
    // how to proceed.
    //
    return(BL_CHECK_UPDATE_FN_HOOK());
#else
    uint32_t *pui32App;

#ifdef ENABLE_UPDATE_CHECK
    g_ui32Forced = 0;
#endif

    //
    // See if the first location is 0xfffffffff or something that does not
    // look like a stack pointer, or if the second location is 0xffffffff or
    // something that does not look like a reset vector.
    //
    pui32App = (uint32_t *)APP_START_ADDRESS;
    if((pui32App[0] == 0xffffffff) ||
       ((pui32App[0] & 0xfff00000) != 0x20000000) ||
       (pui32App[1] == 0xffffffff) ||
       ((pui32App[1] & 0xfff00001) != 0x00000001))
    {
        return(1);
    }

我认为引导加载程序从0x4000开始对应用程序的闪存进行顺序重新编程、当它接收到软件更新时、是这样吗？ 这就是为什么 MSP432在取得大约80%的进度后闪存进程失败时出现错误、因为它已经将看起来是有效堆栈指针的内容刷入了0x4000处应用程序存储器基址、并重置矢量的原因。 当 MSP432复位时、引导加载程序会直接跳转到损坏的应用程序(使用外观有效的堆栈指针和复位矢量)、并且无法通过以太网恢复器件、因为引导加载程序不会广播 BOOTP 消息并等待更新。

我不确定您是否知道可以让 MSP432引导加载程序 BSL_Scripter 工具在所有时间都可靠地工作、从而实现闪存？ 或者、您是否知道可以克服此限制的任何不同工具/引导加载程序组合？

使 MSP432在闪存发生故障后可恢复的另一种方法是、如果应用程序基础上有有效的外观矢量、则在跳转到应用程序之前、广播 BOOTP 消息并每次等待更新约5秒(或某些指定的超时) (可能是损坏的应用程序、也可能不是损坏的应用程序)。 我可以看到 bl_startup_ccs.s 中的 ResetISR 函数在 CheckForceUpdate 函数在应用存储器底部没有返回有效表后跳转到 UpdateBOOTP 函数。

;;*****************************************************************************
;;
;; The reset handler, which gets called when the processor starts.
;;
;;*****************************************************************************
    .thumbfunc ResetISR
ResetISR: .asmfunc
    ;;
    ;; Enable the floating-point unit.  This must be done here in case any
    ;; later C functions use floating point.  Note that some toolchains will
    ;; use the FPU registers for general workspace even if no explicit floating
    ;; point data types are in use.
    ;;
    movw    r0, #0xED88
    movt    r0, #0xE000
    ldr     r1, [r0]
    orr     r1, r1, #0x00F00000
    str     r1, [r0]

    ;;
    ;; Initialize the processor.
    ;;
    bl      ProcessorInit

    ;;
    ;; Call the user-supplied low level hardware initialization function
    ;; if provided.
    ;;
 .if $$defined(BL_HW_INIT_FN_HOOK)
    .ref    BL_HW_INIT_FN_HOOK
    bl      BL_HW_INIT_FN_HOOK
 .endif

    ;;
    ;; See if an update should be performed.
    ;;
    .ref    CheckForceUpdate
    bl      CheckForceUpdate
    cbz     r0, CallApplication

    ;;
    ;; Configure the microcontroller.
    ;;
    .thumbfunc EnterBootLoader
EnterBootLoader:
 .if $$defined(ENET_ENABLE_UPDATE)
    .ref PinoutSet
    bl PinoutSet
    .ref    ConfigureEnet
    bl      ConfigureEnet

UpdateBOOTP 函数位于 bl_emac.c 文件中、ResetISR 将调用此函数来处理此更新。 但是、 同一文件 bl_emac.c 中还有一个 BOOTPThread (void)函数、该函数与 MSP432在广播这些 BOOTP 消息和启动 TFTP 文件传输时实际执行的操作更加一致。 软件更新中使用了以下哪些函数(UpdateBOOTP 或 BOOTPThread)？BOOTPThread 函数在何处启动/调用？ 是否可以在超时并跳转到看上去有效的应用程序之前，实施此 x 秒延迟来广播 BOOTP 消息以进行软件更新？

感谢你的帮助。

Unknown 说：

我认为引导加载程序从0x4000开始对应用程序的闪存进行顺序重新编程当它收到软件更新时，是这样吗？

没错。

Unknown 说：

这将解释当闪存进程在取得大约80%的进度后失败时为什么 MSP432会变砖、因为它已经将看起来像有效堆栈指针的内容刷写到0x4000处应用程序内存基址。 当 MSP432复位时、引导加载程序直接跳转到损坏的应用程序(使用外观有效的堆栈指针和复位矢量)、并且无法通过以太网恢复器件、因为引导加载程序不会广播 BOOTP 消息并等待更新。

我不清楚你在这里的发言。 80%之后闪存过程失败、这意味着什么？ 您是否意味着软件更新未100%完成、并且在复位后、引导加载程序会在0x4000处跳转到应用程序、并且由于应用程序下载不完整而无法运行应用程序？ 如果是这种情况、您需要将 CRC 添加到引导加载过程中。 在引导加载程序跳转到应用程序之前、它将首先检查程序映像的 CRC 是否正确。 如果 CRC 失败、引导加载程序将不会跳转到应用程序、而是进入引导加载模式。  

有关详细信息、请参阅引导加载程序中的 bl_config.h 文件。  

//*****************************************************************************
//
// Enables runtime and download CRC32 checking of the main firmware image.
// If this is defined, the boot loader will scan the main firmware image for
// an image information header (stored immediately above the vector table and
// marked by the words 0xFF01FF02 and 0xFF03FF04). If the header is found and
// the CRC32 value it contains matches that calculated for the image, the
// firmware is run. If the CRC32 does not match or the image information
// is not found, the boot loader retains control and waits for a new download.
// To aid debugging, if this option is used without ENFORCE_CRC being set, the
// image will also be booted if the header is present but the length field is
// set to 0xFFFFFFFF, typically indicating that the firmware file has not been
// run through the post-processing tool which inserts the length and CRC values.
//
// Note that firmware images intended for use with CRC checking must have been
// built with an 8 word image header appended to the top of the vector table
// and the binary must have been processed by a tool such as tools/binpack.exe
// to ensure that the required length (3rd word) and CRC32 (4th word) fields
// are populated in the header.
//
// Depends on: ENFORCE_CRC
// Exclusive of: None
// Requires: None
//
//*****************************************************************************
//#define CHECK_CRC

//*****************************************************************************
//
// This definition may be used alongside CHECK_CRC to remove the debug behavior
// which will allow an image with an uninitialized header to be run. With
// ENFORCE_CRC defined firmware images will only be booted if they contain a
// valid image information header and if the embedded CRC32 in that header
// matches the calculated value.
//
// Depends on: None
// Exclusive of: None
// Requires: CHECK_CRC

//*****************************************************************************
//#define ENFORCE_CRC

//*****************************************************************************

MSP432E BSL 用户指南也提供了详细信息。  https://www.ti.com/lit/pdf/slau746

尊敬的 Charles：

感谢您指向引导加载程序的配置文件。 启用 CRC 校验将能够解决引导加载程序跳转到损坏的应用程序中的问题。

我能够使用下面的线程作为参考、在我的 C++ ti-RTOS 应用程序的矢量表之后创建适当的标头

RTOS/TM4C1294NCPDT：TI-RTOS 的 CRC 接头-基于 Arm 的微控制器论坛-基于 Arm 的微控制器- TI E2E 支持论坛

我的代码：

#pragma LOCATION(0x4040)
#pragma RETAIN
static const unsigned char myCRC[32] = {
                               0xFF, 0x01, 0xFF, 0x02, //predefined header - first word
                               0xFF, 0x03, 0xFF, 0x04, //predefined header - second word
                               0xFF, 0xFF, 0xFF, 0xFF, //word to be replaced with image length by binpack
                               0xFF, 0xFF, 0xFF, 0xFF, //word to be replaced with CRC32 by binpack
                               0xFF, 0xFF, 0xFF, 0xFF, //reserved word
                               0xFF, 0xFF, 0xFF, 0xFF, //reserved word
                               0xFF, 0xFF, 0xFF, 0xFF, //reserved word
                               0xFF, 0xFF, 0xFF, 0xFF //reserved word
};

我的.txt 文件的开头：

@4000
00 FC 03 20 C9 0E 06 00 61 EA 06 00 61 EA 06 00 
61 EA 06 00 61 EA 06 00 61 EA 06 00 61 EA 06 00 
61 EA 06 00 61 EA 06 00 61 EA 06 00 61 EA 06 00 
61 EA 06 00 61 EA 06 00 37 F0 06 00 
@4040
FF 01 FF 02 FF 03 FF 04 FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
2D E9 F0 4F 91 F8 3D 30 91 F8 3C 20 42 EA 03 22 
91 F8 3E 30 42 EA 03 42 91 F8 3F 30 AD F1 74 0D 
42 EA 03 62 08 92 91 F8 39 30 91 F8 38 20 42 EA 
03 22 91 F8 3A 30 42 EA 03 42 91 F8 3B 30 42 EA 
03 62 0C 92 91 F8 35 30 91 F8 34 20 42 EA 03 22 
91 F8 36 30 42 EA 03 42 91 F8 37 30 42 EA 03 62 
06 92 91 F8 31 30 91 F8 30 20 42 EA 03 22 91 F8 
32 30 42 EA 03 42 91 F8 33 30 42 EA 03 62 13 92 

我还在下面添加了构建后步骤、以创建 bin 文件。

"$｛CCE_INSTALL_ROOT｝/utils/tiobj2bin/tiobj2bin.bat "$｛BuildArtifactFileName｝""$｛BuildArtifactFileBaseName｝.bin""$｛CG_TOOL_ROOT｝/bin/ofd470.exe "$｛CG_TOOL_ROOT｝/bin/hex470.exe "$｛CCE_INSTALL_ROOT｝/utils/tiobj2bin/mkhex4bin.exe "

我在 MSP432 SDK 中找不到 binpack 工具、您可以告诉我该位置吗？ 但我在 TivaWare_C_Series-2.2.0.295中发现了该工具。

但是、当我尝试导入.bin 文件时、从 binpack 中收到以下错误：
错误：输入图像格式无效。
输入文件在矢量表的顶部不包含图像信息标头！
运行此工具之前、请确保存在该窗口。

对此有何建议？ 谢谢。

您好、Parry、

 您能否参阅 TivaWare 文档文件夹中的用户指南(SW-TM4C-TOOLS-ug-2.2.0.295.pdf)了解详细信息？ 我建议您首先生成.bin、然后手动执行 binpack、而不是在 CCS 编译后过程中进行嵌入。 隔离问题将更容易。  

尊敬的 Charles：

我尚未将 binpack 集成到 post-build 过程中。 我只是使用 ti/ccs 工具文件夹中的 tiobj2bin 工具将.out 文件转换为.bin 文件集成到编译后处理中。

我当前正在尝试使用以下命令使 binpack 工具手动工作：

binpack -i Program.bin -o Program_output.bin  

但我得到错误：

错误：输入图像格式无效。
输入文件在矢量表的顶部不包含图像信息标头！
运行此工具之前、请确保存在该窗口。

我不确定我使用上述#pramga 指令创建的8字标头是否有任何问题、但 binpack 无法在我生成的.bin 映像中找到正确的标头。

我已经阅读了  您建议的 SW-TM4C-TOOLS-UG-2.2.0.295.pdf 手册中的部分、但-d 选项似乎会附加不同类型的8字节标头、这与引导加载程序的 CRC 检查无关。

您是否知道 我需要如何添加标头来允许 binpack 将长度和 CRC 信息替换到标头上的正确字词中？ 成功生成这个.bin 文件后、我需要将其刷写到 MSP432中、并能在以太网引导加载程序上测试 CRC 校验(我是否需要将.bin 文件转换回.out 文件？)

谢谢。

这是我的.out/.bin 文件(为 BSL 以太网引导加载程序以 txt 格式生成)开头部分的屏幕截图、其中使用了#pragma 指令插入了其他标头、也没有插入其他标头。

您知道为什么 binpack 无法检测到矢量表顶部的标头并抛出错误吗？

以下是运行命令：binpack -i Program.bin -o Program_output.bin -v 时该工具的详细输出屏幕截图。

这些设置对于具有上面显示的标头的文件是否正确？

您好、Parry、

 我认为您的二进制文件可能有两个问题。  

 -首先,您的8字标题从0x4040开始。 这意味着您的中断矢量表只有64个字节。 根据 CHECK_CRC 的说明、它需要位于中断矢量表的"顶部"。 在矢量表中、最后一个条目位于0x000041FC。 这意味着标头应该从0x00004200开始、在我看来不是0x4040。  

 第二,如果你的程序将从0x4000开始,那么你需要指定-a 0x4000 -d 到 binpack.exe 我没有在你的命令行看到.  

Unknown 说：

看起来标题总是放在处理器异常(重置 vec 等)中断表之后、然后放在其余中断向量之前(假设字节2d e9之后是中断向量)。

您好、Parry、

 我认为2D E9是程序图像的其余部分、而不是中断矢量。  

Unknown 说：

我尝试从代码中放置标头的方式是否有问题？ 我不确定如何将其放置在中断矢量之后的0x4200处。
[/报价]

我猜你的问题可能是因为 endianism。 在上面的图像中、您将按字节顺序写入标头、如在0xFF、0x01、0xFF、0x02中。 但如果您将其视为32位字、它将为0x02FF01FF。 您可以在32位 CCS 存储器浏览器中查看。 请尝试按小端字节序的顺序输入 myCRC 数组中、即0x02、0xFF、0x01、0xFF 以及接下来的4个字节。 尝试查看这是否解决了问题。  

Unknown 说：

应用程序.cmd 文件：

全屏

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

--- stack_size=1024 /* C 堆栈也用于 ISR 堆栈*/

#define APP_BASE 0x00004000

HEAPSIZE = 0x20000；/* HeapMem 使用的堆缓冲区的大小*/

内存

{

FLASH (RX)：origin = APP_BASE，length = 0x00100000

SRAM (rwx)：origin = 0x20000000、length = 0x00040000

｝

/*内存中的段分配*/

部分

{

.text :>闪存

.const :>闪存

.rodata :>闪存

cinit :>闪存

请输入您的密码:> FLASH

init_array：> FLASH

[/报价]

您的申请长度不正确。 如果您正在启动应用程序0x04000、则长度应如下所示。

FLASH (RX)：origin = APP_BASE，  length = 0x000FC000

我还建议您首先使用一个简单的非 TI-RTOS 映像、如闪烁示例。 非 RTOS 示例已完整填写中断矢量表。 但在 TI-RTOS 示例中、并未完全填充所有默认条目的表格。 我不知道这是否会使 binpack.exe 在尝试找到中断矢量表的顶部时产生影响。 查看您是否可以首先使非 TI-RTOS bin 文件工作、然后再转到 TI-RTOS bin 文件。  

[/quote]

尊敬的 Charles：

感谢您的答复。 字节序绝对是 binpack 工具检测头的问题、我按照您的建议更改了它、该工具能够在我的.bin 文件上运行。

我在链接器文件中更正了我的应用程序的长度。

下面是这两条 binpack 命令的比较(其中一条命令在开头添加了一个8字节标头、我不确定这是否有必要)

binpack -i Program.bin -o Program_output.bin -v

binpack -i Program.bin -o Program_output-w-header.bin -a 0x4000 -d -v

我能够使用 UniFlash 将这个新的 bin 文件 Program_output.bin (开头没有8字节标头)刷写到 MSP432、在 bl_config.h 文件中启用 ENABLE_CRC 和 FORCE_CRC 选项的情况下、在将 I FLASH 单独刷写到引导加载程序中。

是否存在允许 Code Composer 将新的 Program_output.bin 文件转换为.out 文件并将其用作刷写到 MSP432中的工件的方法？ 它还需要生成.txt 文件、以使用 BSL_Scripter 发送该文件。 由 code composer 生成的.out 和.txt 文件当前没有 CRC 和长度信息、因为这是由 binpack 单独完成的。 我需要能够使用 Code Composer 来调试该项目以使其继续。

我通过查看上面 Program_output.bin 中的十六进制文件来添加 CRC 和长度信息、手动编辑了 Code Composer 生成的.txt 文件。 当我尝试使用 BSL Scritper 发送它时、没有 BOOTP 消息、我不知道代码是否成功跳转到引导加载程序、因为我无法通过 Code Composer 对它进行调试。

感谢你的帮助。

Unknown 说：

感谢您的答复。 字节序绝对是 binpack 工具检测头的问题、我按照您的建议更改了它、该工具能够在我的.bin 文件上运行。

我在链接器文件中更正了我的应用程序的长度。

[/报价]

Unknown 说：

我能够使用 UniFlash 将此新 bin 文件 Program_output.bin (开头没有8字节标头)刷写到 MSP432、在我在 bl_config.h 文件中启用 enable_crc 和 force_crc 选项的情况下单独刷写到引导加载程序中。

您好、Parry、

 很高兴您取得了进展、问题得到解决。  

Unknown 说：

是否存在允许 Code Composer 将新的 Program_output.bin 文件转换为.out 文件并将其用作闪存到 MSP432的工件的方法？

没有转换器可将 bin 文件转换回.out 文件。 bin 文件不包含调试符号、而.out 文件则包含调试符号。 这就是.out 文件将大于.bin 文件的原因。 首先、您可以使用.bin 文件加载程序。 固件编程完毕后、可使用"Load Symbol"命令仅添加符号。 您仍可提供.out 文件、但该文件仅添加符号、不会使用 JTAG 对固件进行重新编程。 您可以对引导加载程序和应用程序执行相同的操作以进行调试。  

[/quote]

尊敬的 Charles：

从您的屏幕截图可以看出、您好像已经启动了一个调试会话、您是通过首先加载.bin 文件来执行此操作吗？ 您能告诉我在 bin 文件中加载符号的步骤、然后再从 out 文件中加载符号进行调试吗？ 我不知道如何使用.bin 文件启动调试会话。 我想我需要启动调试会话才能在"Run"下拉列表中看到这些选项。

谢谢。

您好、Parry、

 在一个简单的闪烁非 RTOS 示例上尝试该操作。 首先通过 JTAG 加载 blinky.bin 或任何简单的程序。 您应该会看到 LED 在闪烁、但如果使用 CCS 连接到器件、则没有可查看的源代码。 现在点击"Load Symbols"并指定 blink.out、您将看到添加的源代码和调试符号。  

尊敬的 Charles：

谢谢进行说明、但我仍然不了解从 Code Composer 上载.bin 文件、然后再从.out 文件添加符号的步骤。 我没有与"Run"选项卡下相同的选项。 您能解释一下步骤吗？

不过、我在 bl_config 中添加了"Enforce_crc"注释、成功地使用 CCS 项目中的.out 文件工件进行调试。 注释中提到、这是用于调试、因此只要存在 CRC 头文件、就无需提供实际的 CRC 值和长度信息即可跳转到应用-进行调试。

成功启用 CRC 后、我获得的结果与引导加载程序不一致。 我知道现在是否正在进行检查、但如果 CRC 错误/不存在、引导加载程序仍会跳转到应用程序、应该不会发生这种情况。

我想我在引导加载程序中 bl_check、c 文件中的 CheckForceUpdate 函数出现了问题。

我们可以从 bl_startup_ccs.s 文件中看到、如果有应用程序跳转到 CheckForceUpdate 函数返回0、而我们跳转到 CallApplication。 否则，我们应继续使用 EnterBootLoader，BOOTP 消息应开始出现在网络上。

我知道，如果闪存中只有引导加载程序并且不存在应用程序，我们将继续 EnterBootLoader 并在网络上查看 BOOTP 消息。 下面显示了 CheckForceUpdate 函数的这个退出点、它是应该出现的正确行为：

但是、如果有一个应用程序但它已损坏并且 CRC 错误、则 CheckForceUpdate 函数有一个不同的退出点、如下所示：


我认为如果 CRC 错误、并且我们返回(2)、 bl_startup_ccs.s 文件中的 CBZ 指令未能正确处理此内容、我们仍跳到了损坏的应用程序。 我将此语句更改为返回(1)、现在我要从引导加载程序中观察到正确的行为。 如果 CRC 错误或不存在，我们继续使用 EnterBootLoader，现在可以在网络上看到 BOOTP 消息。

为什么这里有一个退货(2)声明？ 这只是 MSP432 SDK 中的引导加载程序代码中的一个拼写错误、还是有原因？ 我还可以看到、这是 sdk\source\ti\devices\msp432e4\boot_loader 中引导加载程序库代码中存在 return (2)语句的唯一位置。

感谢您的帮助。

您好、Parry、

 我首先使用 Uniflash 加载.bin 文件。 请参见下方的。  

接下来、我使用 CCS 连接到目标。 我可以查看闪存内容、但不能查看调试符号和源代码。  

接下来、我通过提供相应的.out 文件来"添加符号"。 请记住、这仅用于添加符号。 它不会对闪存重新编程。

尊敬的 Charles：

感谢您向我展示如何执行该操作。

在获得具有 CRC 校验的可靠引导加载程序之前、我还需要清除一些事项。

问题1：

我已经缩小了范围、它看起来像是 bl_check.c 中 CheckForceUpdate 函数中代码的特定部分、它检查 app_start_address 处是否有看起来有效的矢量表、这会导致 CRC 实现中断。

我突出显示了下面的代码(我已在此处将其停用、但这是一项在检查 CRC 之前始终在该函数中运行的检查)。

这是我在问题部分激活/停用时观察到的情况：

• 有问题段(检查复位向量和堆栈指针)：
  • 有效 CRC ->引导至应用程序
  • 无效 CRC -> 无法引导至应用程序、但没有 BOOTP 请求-砖型 MSP432  
• 无问题段(已停用复位向量和堆栈指针)：
  • 有效 CRC ->引导至应用程序
  • 无效 CRC -> 不引导至应用程序、发送 BOOTP 请求-允许对 MSP432进行固件恢复

我还没有弄清楚为什么这个 if 语句改变了一个有效/无效 CRC 的行为、你知道这可能是为什么吗？ 如果我错了，请更正我，我认为当 CRC 无效且我们未引导到应用程序(突出显示为绿色)时应该有 BOOTP 请求-这就是我希望看到的功能。

我可能会在 MSP432 SDK 提供的 bl_check.c 文件中停用这项检查、从而克服这一问题。 启用 CRC 后、无需对复位向量和堆栈指针进行此类检查、因为 CRC 计算包括复位向量和堆栈指针。

你对我为什么要讨论这个问题有什么想法吗？

问题2：

BSL_Scripter 工具使用由 CCS 中的 Arm Hex 实用程序生成的.txt 文件、通过以太网将代码发送到 MSP432。 我的两个编译后处理步骤基本上是获取.out 文件工件并将其转换为.bin 文件、然后 binpack.exe 向标头中添加必要的长度和 CRC 信息：
1."$｛CCE_INSTALL_ROOT｝/utils/tiobj2bin/tiobj2bin.bat "$｛BuildArtifactFileBaseName｝.out""$｛BuildArtifactFileBaseName｝.bin""$｛CG_TOOL_ROOT｝/bin/ofd470.exe ""$｛CG_TOOL_ROOT｝/bin/hex470.exe ""$｛CCE_INSTALL_ROOT｝/utils/tiobj2bin/mkhex4bin.exe "
2."c：/ti/binpack/binpack.exe -i "$｛BuildArtifactFileBaseName｝.bin"-o "$｛BuildArtifactFileBaseName｝_output.bin"-x

由于来自 Arm Hex Utility 的.txt 文件是从.out 文件转换的、因此它不包含我在 binpack 之后需要从.bin 文件中获取的长度和 CRC 信息。 是否有工具可以将.bin 文件转换为 BSL 脚本程序可以使用的.txt 文件？

此外、我还尝试了使用长度和 CRC 信息来手动编辑.txt 文件、但 CRC 计算似乎存在错误？ 在从 BSL_Scripter 接收到文件后、引导加载程序不会引导到应用程序中、而是等待发送 BOOTP 请求(当突出显示的 if 语句已停用时)。

感谢您对此提供的帮助。 谢谢。

Unknown 说：

这是我在问题部分激活/停用时观察到的情况：

• 有问题段(检查复位向量和堆栈指针)：
  • 有效 CRC ->引导至应用程序
  • 无效 CRC -> 无法引导至应用程序、但没有 BOOTP 请求-砖型 MSP432  
• 无问题段(已停用复位向量和堆栈指针)：
  • 有效 CRC ->引导至应用程序
  • 无效 CRC -> 不引导至应用程序、发送 BOOTP 请求-允许对 MSP432进行固件恢复

[/报价]

您好、Parry、

 引导加载程序将检查有效的应用程序矢量表。 有效的向量表表示堆栈指针和复位向量并非全部为 F。 如果它们是 F、则表示这不是有效的矢量表。   

Unknown 说：

是否有工具可以将.bin 文件转换为 BSL 脚本程序可以使用的.txt 文件？

在 BSL Scripter 用户指南 https://www.ti.com/lit/pdf/slau655中、 其中介绍了如何生成.txt 文件。  

我还想给你一个提示,我将是 OOO 从明天开始,直到下周二. 我的回复会延迟很多、因为我可能无法访问互联网。  

[/quote]

尊敬的 Charles：

感谢您的答复。

我知道代码会检查有效的矢量表。 但是、该矢量表检查会导致 CRC 实现中断。 如果上传的应用程序带有无效的 CRC，则不会从引导加载程序接收到任何 BOOTP 消息，从而使设备无法通过以太网恢复。 为什么会发生这种情况？

至于.txt 文件生成器、我知道 CCS 中的 Arm Hex 工具可以从.out 文件生成.txt 或.hex 文件、但.out 文件不是构建过程的最终成果。 如上所述、我的编译步骤会创建一个_output.bin 文件、该文件由包含 CRC 和长度头信息的 binpack 生成。 我需要使用 BSL_Scripter 将这个.bin 转换为.txt 或.hex 文件以通过以太网发送、但十六进制工具似乎不支持将.bin 作为输入文件格式。

如果我尝试使用 Arm Hex 工具将 CRC 和长度信息手动添加到由.out 文件生成的.txt 文件中、则会出现 CRC 错误、并且它不会引导到我的应用程序中、而是在网络上发送 BOOTP 请求。

请查看此内容、因为我遇到从上述用户手册中找不到相关信息的问题。

您好、Parry、

 很抱歉、我在度假。 此时我正在旅行。 我会在下周回来的时候给你回复。 同时、请查看您能否自行取得一些进展。 我真的很抱歉。