[参考译文] AM62A7：使用来自 SBL 的 MMCSD_WRITE 时系统崩溃

您好！

客户是否已测试以下 MMCSD_RAW_IO 示例？

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62AX/10_00_00_14/exports/docs/api_guide_am62ax/EXAMPLES_DRIVERS_MMCSD_RAW_IO.html

此致、

Prashant

Prashant、您好！

感谢您的答复！

客户按照上面的示例说明他们的用例。 它们运行的示例并不完全相同、因为它们的用户案例有些不同。

但是、客户确认的是、只要他们使用  MMCSD_WRITE 系统将会崩溃。

客户还提到、如果他们首先使用 MMCSD_READ、然后运行以下代码对 eMMC 进行分区、则系统也会崩溃。 (如果它们直接运行以下代码而不运行 MMCSD_READ、则这是正常情况)

uint8_t read_emmc_partition_config(MMCSD_Handle handle) {
    MMCSD_Transaction trans;
    uint8_t extCsdData[512] = {0};

    MMCSD_initTransaction(&trans);
    trans.cmd = MMCSD_MMC_CMD(8); 
    trans.dir = MMCSD_CMD_XFER_TYPE_READ;
    trans.arg = 0; 
    trans.blockCount = 1;
    trans.blockSize = 512;
    trans.dataBuf = extCsdData; 

    int status = MMCSD_transfer(handle, &trans);
    if (status != 0) {
        return 0xFF;
    }

    uint8_t partitionConfig = extCsdData[179];
    return partitionConfig;
}

客户认为 SMS 中似乎有计时器、客户是否执行了上述操作、未及时提供看门狗、从而导致了此问题？

BTW、如果客户从 Linux 端操作 eMMC、则没有问题。

谢谢！

Kevin

我通过示例测试、它也不起作用

它进入循环、请参考下图  

看起来执行甚至没有到达示例的主函数。 我想知道您实际上是如何运行或引导示例吗？

我使用 SBL 进行引导并通过 CCS 加载它、并在调试其他示例时使用相同的方法。

此外、我在 SBL 中描述的问题在不运行 main 函数的情况下似乎就存在问题、因为在 main 函数初始化完成后、信息通过串行端口输出、但在下载 MMCSD_WRITE 函数操作的映像之后、不会输出任何串行端口信息

Prashant、您好！

我是否可以知道 Tom 的运行步骤是否是预期的、或者您是否需要他进行一些修改才能运行此示例？

谢谢！

Kevin

Unknown 说：

使用 SBL 进行自举并通过 CCS 加载 SBL、我在调试其他示例时使用相同的方法。

这是不正确的方法。 不能使用 CCS 运行 WKUP R5F 示例。 它们必须由 SBL 引导、如下所述：

AM62Ax MCU+ SDK：在器件管理器/唤醒 R5内核上开发应用

我使用这种方法测试其测试通过的示例。

对于我的问题、是否有分析方法？

我参考 https://software-dl.ti.com/mcu-plus-sdk/esd/AM62AX/10_00_00_14/exports/docs/api_guide_am62ax/DEVELOP_AND_DEBUG_DMR5.html 的链接 来调试我的代码。 添加流代码时使用 CCS 调试、操作成功。

    {
        uint8_t writeBuff[1024] = {0x11,0x12,0x13,0x14,0x15,0x15,0x16,0x18,0x19,0x20};
        uint8_t readBuff[1024];
        status = MMCSD_write(gMmcsdHandle[0], writeBuff, 35, 1);
        LogServ_DebugInfo(  LOGSERV_LOG_CHANNEL_MASK_UART, 
                            LOGSERV_LOG_LEVEL_INFO, 
                            SBL1_MAIN_SW_MODULE_ID, 
                            SBL1_MAIN_API_ID_main, 
                            0,
                            NULL,
                            "MMC Write Data: status = %d\r\n",status);

        status = MMCSD_read(gMmcsdHandle[0], readBuff, 35, 1);
        LogServ_DebugInfo(  LOGSERV_LOG_CHANNEL_MASK_UART, 
                            LOGSERV_LOG_LEVEL_INFO, 
                            SBL1_MAIN_SW_MODULE_ID, 
                            SBL1_MAIN_API_ID_main, 
                            0,
                            NULL,
                            "MMC Read Data: status = %d,Data:0x%x 0x%x 0x%x 0x%x\r\n",status,readBuff[0],readBuff[1],readBuff[2],readBuff[3]);
    }

但我使用相同的代码,将映像刷写到芯片,它将崩溃。

闪存方法：

-使用 USB DFU 闪存 dm-am62ax-sbl_eMMC_stage1.release.hs_fs.tiimage 文件

当我删除上述代码并使用相同的方法刷写映像时,它不会崩溃

您对此问题有何看法？

Unknown 说：

添加的流代码使用 CCS 调试时、操作成功。

Unknown 说：

-使用 USB DFU 闪存 dm-am62ax-sbl_eMMC_stage1.release.hs_fs.tiimage 文件[/报价]

 您能否解释一下您在上述两种情况下所遵循的确切步骤？ 另请分享启动日志。

您是指 USB DFU 闪存映像步骤？ 请参阅的链接  3.1.2. USB 器件固件升级(DFU)—处理器 SDK AM62x 文档

请按照下列步骤操作

-添加以上代码

-编译代码和生成的 fs_fs.tiimage 文件

-使用引导模式到 USB DFU

-使用 USB-DFU 工具刷新映像

-将引导模式切换到 eMMC

-接通电源, UART NOT OUTPUT 任何信息

当删除上述代码时、使用上述步骤闪存、然后打开电源。 UART 有输出信息。 以下信息  

Unknown 说：

-打开 UART 电源 NOT OUTPUT 任何信息[/报价]

此时您是否可以使用调试器、连接到 WKUP R5F 内核、并记下内核暂停的地址？

后面的地址和映射文件

Prashant、您好！

客户分析过、这种卡滞是由于 WKUP 内核正在等待来自 TIFS 的响应。

以前、客户没有在 main 中添加 eMMC 写入、因此没有此类问题。 现在、客户在 main 中添加 eMMC 写入后、它将满足此问题。 客户不了解为什么在 main 中添加 eMMC 写入会影响 TIFS 响应。

我可以知道你是否有任何线索这一点吗?

谢谢！

Kevin

// cmd files

@echo off
set MODE=%1

if "%MODE%"=="sbl" (
    py.exe .\dfu_flash.py -d am62axx-hw-a -t hsfs -c bin\am62axx-hw-a\hsfs\emmc-flash\dm-linux-rt-am62a7-single-emmc-sbl.cfg
) else if "%MODE%"=="spl" (
    py.exe .\dfu_flash.py -d am62axx-hw-a -t hsfs -c bin\am62axx-hw-a\hsfs\emmc-flash\dm-linux-rt-am62a7-single-emmc-spl.cfg
) else (
    echo Invalid parameter. Please use 'sbl' or 'spl'.
    exit /b 1
)

pause


// dfu_flash.py
# Standard modules
import argparse
import os
import logging

# Custom modules
import src.logger
from src.flash import dfu_main
from src.parse import parse_cfg_file, get_command
from src.helper import dump_dfu_flash_conf, dump_dfu_boot_conf
from src.constants import BIN_DIR_PATH, FLASH_CFG_FILE_NAME, UENV_TEMPLATE, UENV_GPT_MMC

def main():
    # Define the argument parser
    args_parser = argparse.ArgumentParser()

    # Argument to identify the device
    args_parser.add_argument("-d",
                             "--device",
                             required=True,
                             help="Specify the device",)

    # Argument to identify the type of the device
    args_parser.add_argument("-t",
                             "--type",
                             required=True,
                             choices=["gp", "hsfs", "hs"],
                             help="Type of the device",)

    # Argument to get the path of the custom configuration file
    args_parser.add_argument("-c",
                             "--cfg",
                             help="Path to the flashing configuration file",)

    # Argument to reset the board after flashing
    args_parser.add_argument("-r",
                             "--reset",
                             action="store_true",
                             help="Reset the board to the flashed media",)

    # Parse the CLI arguments
    args = args_parser.parse_args()
    cli_args = {
        "device": args.device,
        "type"  : args.type,
        "cfg"   : args.cfg,
        "reset" : args.reset
    }

    # Validate the CLI arguments
    logging.info("Starting the flashing tool")
    logging.info("Validating the requirements before flashing...")

    # Path to the device directory
    DEVICE_PATH = BIN_DIR_PATH / cli_args["device"] / cli_args["type"]

    # Check if device path exists
    if not os.path.exists(DEVICE_PATH):
        logging.error(f"The device path {{{DEVICE_PATH}}} does not exist!!!")
        exit(1)

    # Path to the flash configuration file
    cfg_file = cli_args["cfg"]

    # If custom flash configuration file not given, use the default one
    if not cfg_file:
        cfg_file = DEVICE_PATH / FLASH_CFG_FILE_NAME

    if not os.path.exists(cfg_file):
        logging.error(f"The flash configuration file {{{cfg_file}}} does not exist!!!")
        exit(1)

    # Path to the DFU boot images
    dfu_tiboot3 = DEVICE_PATH / "tiboot3.bin"
    dfu_tispl   = DEVICE_PATH / "tispl.bin"
    dfu_uboot   = DEVICE_PATH / "u-boot.img"

    for path in [dfu_tiboot3, dfu_tispl, dfu_uboot]:
        if not os.path.exists(path):
            logging.error(f"The DFU boot binary {{{path}}} does not exist!!!")
            exit(1)

    logging.info("Validated the CLI arguments and the paths to the DFU boot binaries")
    logging.info(f"Parsing the flash configuration file {{{cfg_file}}}...")
        
    # Parse the flash configuration file
    dfu_flash_conf = parse_cfg_file(cfg_file)

    if not dfu_flash_conf:
        logging.error("Could not found any images to flash...")
        exit(1)

    # Get the DFU command
    command = get_command(dfu_flash_conf, cli_args["reset"])

    # Print the DFU flash configuration
    dump_dfu_flash_conf(dfu_flash_conf)

    # Path to the U-Boot environment file
    uEnv_path = DEVICE_PATH / "uEnv.txt"

    # Write the DFU command to U-Boot Environment file
    with open(uEnv_path, 'w') as f:
        # f.write(UENV_GPT_MMC)
        f.write(UENV_TEMPLATE.format(command))

    dfu_boot_conf = {
        "bootloader" : dfu_tiboot3,
        "tispl.bin"  : dfu_tispl,
        "u-boot.img" : dfu_uboot,
        "uEnv.txt"   : uEnv_path,
    }

    # Print the DFU boot configuration
    dump_dfu_boot_conf(dfu_boot_conf)

    # Start the DFU main function
    dfu_main(dfu_flash_conf, cli_args)

if __name__ == '__main__':
    main()

这看起来是正确的。

您是否可以使用以下命令尝试直接通过 USB DFU 引导模式启动映像、而不是进行刷写。

dfu-util -a bootloader -D <path to .hs_fs.tiimage>

如果仍然看不到任何日志、请检查 wkup 内核暂停的地址、以确认 SBL 是否至少正在引导。

您好、Prashant

我使用 USB DFY 引导 SBL、它可以看到日志并可以执行 MMCSD_WRITE 操作。

如何在使用 eMMC 引导时确保启用 SBL？

在上面的答案中、在 SBL 映射中未找到 CPU 支持地址、这意味着 SBL 未运行？

Unknown 说：

我使用 USB DFY 引导 SBL、它可以查看日志并执行 MMCSD_RE写 操作。

如果该器件通过 USB DFU 引导模式正确引导和执行、则 eMMC 刷写或其配置存在问题。

您可以一次尝试从 MCU+ SDK 中的 UART_UNIFLASH 来刷写映像并查看它是否启动？

我想我们现在讨论的主题不是因为使用 USB FDU 进行刷写后无法引导、而是因为我们刷写了添加了 MMCSD_WRITE 功能的映像而无法引导。

因为我删除 MMCSD_WRITE 函数时、它开始可以使用相同的刷写方法

我之前使用了 UART_UNIFLASH 进行刷写、它可以正常启动、但之前刷写的映像没有添加 MMCSD_WRITE 函数

Prashant、您好！

感谢您的支持、客户可以使用 UART_UNIFLASH 引导、他们以前也曾尝试过、也可以使用您提供的示例引导。

此问题与  MMCSD_WRITE 功能有关、正如 Tom 提到的、您可以帮助检查 MMCSD_WRITE 为何会影响引导吗？

非常感谢、

Kevin

Prashant、您好！

我想知道您的建议、我们接下来可以尝试哪些操作吗？

我们现在不知道该怎么做、可能需要您的帮助。

谢谢！

Kevin

Unknown 说：

因为当我删除 MMCSD_write 函数时、开始使用相同的刷写方法即可

您能否与此功能(假设不引导)和没有此功能(假设引导)共享映像？

Prashant、您好！

感谢您的答复。

用于引导情况(不使用 MMCSD_WRITE)

UART 启动映像如下所示。

电流测量值为 0.235A 如下所示。

引导情况的 SBL eMMC stage1 tiimage 如下所示。

e2e.ti.com/.../dm_2D00_am62ax_2D00_sbl_5F00_emmc_5F00_stage1.release.hs_5F00_fs.tiimage_5F00_boot

对于无法引导的情况(使用 MMCSD_WRITE)

UART 不引导映像如下所示。

仅测量电流  0.131A  如下所示。

下面显示了不引导情况的 SBL eMMC stage1 tiimage。

e2e.ti.com/.../dm_2D00_am62ax_2D00_sbl_5F00_emmc_5F00_stage1.release.hs_5F00_fs.tiimage_5F00_not_5F00_boot

客户在引导用例与不引导用例之间的编码唯一不同之处如下所示。

感谢您的帮助、请帮助为我们提供一些可进一步调试的线索。

非常感谢、

Kevin

Unknown 说：

对于无法引导情况(使用 MMCSD_WRITE）

您好、客户在引导此映像之前是否以任何方式修改 EXT_CSD 寄存器？

要从 eMMC boot0分区引导、必须正确设置 EXT_CSD 中的 BOOT_PARTITION 和 BOOT_BUS_WIDTH 字段。

您好、Prashant

在调用 MMCSD_WRITE 函数之前、请勿修改 EXT_CSD 寄存器。

那么、当我调用 MMCSD_WRITE 函数、时、是否应该设置 BOOT_PARTITION 和 BOOT_BUS_WIDTH？ 哪个函数实现了在 MMCSD 驱动程序中设置 BOOT_PARTITION 和 BOOT_BUS_WIDTH？

Prashant、您好！

感谢您的答复。

客户 在调用 MMCSD_WRITE 之前未修改 EXT_CSD 寄存器 。

您能否建议如何 正确设置 MMCSD 驱动程序中的 boot_partition 和 boot_BUS_width？

非常感谢、

Kevin

尊敬的客户：

   您能否  按如下所示更改 gMpuRegionConfig 以进行检查。  谢谢。  

-#define CONFIG_MPU_NUM_REGIONS (9U)

+ -#define CONFIG_MPU_NUM_REGIONS ( 10U)

+｛
+.baseAddr = 0xfa00000u、
+.size = MpuP_RegionSize_2M、
+.attrs =｛
+.isEnable = 1、
+.iscachable = 1、
+.isablable = 1、
+.isSharable = 0、
+.isExecuteNever = 0、
+.tex = 1、
+.accessPerm = MpuP_AP_all_rw、
+.subregionDisableMask = 0x0u
+｝、

Linjun