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.

[参考译文] TDA4VEN-Q1:TDA4VEN-Q1:在 TDA4VEN 定制电路板上使用 UART Uniflash 写入 OSPI 闪存时、UART 在第二次操作后停止的问题

Guru**** 2874030 points

Other Parts Discussed in Thread: UNIFLASH

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1627552/tda4ven-q1-tda4ven-q1-issue-where-uart-stops-after-the-second-operation-when-writing-to-ospi-flash-using-uart-uniflash-on-a-tda4ven-custom-board

器件型号: TDA4VEN-Q1
Thread 中讨论的其他器件: UNIFLASH

概述
在使用 TDA4VEN 的定制电路板上、我们尝试使用 UART Uniflash 通过 UART 对 OSPI NOR 闪存进行编程。
但是、在第一次写入操作(发送闪存写入器 (sbl_uart_uniflash*.tiimage)) 之后、UART 通信始终在第二次写入操作期间停止(例如 PHY 调优或应用映像刷写)、并且刷写过程无法继续。
  • 第一个操作(tiimage 传输)始终成功完成
  • 在第二次操作开始后、UART 立即无响应、XMODEM 传输保持在 0%
  • J722S EVM 上没有出现此问题

问题

  • 启动闪存写入器 (tiimage) 后 UART 无法使用的行为是否是预期行为、或者与 TDA4VEN、UART Uniflash 或 OSPI 相关的已知限制?
  • 使用时uart_uniflash、是否有定制主板上不支持按顺序执行多个闪存写入操作或不可靠的情况?

    对于此问题、我们希望确认根本原因和可能的对策、包括正确的先决条件和建议的操作流程。
详细信息

存在许多风险

  • Board:定制调试板
  • 闪存目标:OSPI NOR 闪存
  • 主机 PC 环境:Ubuntu
  • 刷写方法:UART 引导模式+ uart_uniflash
  • 连接:主机 PC→USB 转 UART 转换器→SoC

程序和发现的问题
使用 UART Uniflash 配置文件、在单次运行中按顺序执行以下步骤:

  1. 发送 sbl_uart_uniflash.release.hs_fs.tiimage
    (通过 UART 引导启动闪存写入器)
  2. 对 OSPI NOR 闪存执行后续写入、例如:
    :OSPI PHY 调优
    :Appimage 闪烁
    :SBL 闪烁

观察到的行为:

  • 第一个命令(tiimage 传输)始终成功完成
  • 在第二条命令开始时、UART 无响应、XMODEM 传输保持在 0%
  • 即使跳过 PHY 调优并且仅--operation=flash使用正常、也会发生相同的问题
  • 下电上电后、只能再次执行第一条命令
  • 此外、重新启动后、第一次尝试总是会导致 NAK 错误、第二次尝试会成功发送 tiimage
实际日志
@Ubuntu:~$ ./uart_uniflash_image.sh                                                                                                                                  

Parsing config file ...
Parsing config file ... SUCCESS. Found 2 command(s) !!!

Executing command 1 of 2 ...
Found flash writer ... sending /home/kozai/cms_proj/uniflash_img/sbl_uart_uniflash.release.hs_fs.tiimage
Sending /home/kozai/cms_proj/uniflash_img/sbl_uart_uniflash.release.hs_fs.tiimage:   0%|                                                                   | 0/329295 [00:00<?, ?bytes/s]send error: expected NAK, CRC, EOT or CAN; got b'c'
send error: expected NAK, CRC, EOT or CAN; got b'1'
send error: expected NAK, CRC, EOT or CAN; got b'1'
send error: expected NAK, CRC, EOT or CAN; got b'9'
send error: expected NAK, CRC, EOT or CAN; got b'a'
send error: expected NAK, CRC, EOT or CAN; got b'3'
send error: expected NAK, CRC, EOT or CAN; got b'7'
send error: expected NAK, CRC, EOT or CAN; got b'5'
send error: expected NAK, CRC, EOT or CAN; got b'1'
send error: expected NAK, CRC, EOT or CAN; got b'2'
send error: expected NAK, CRC, EOT or CAN; got b'7'
send error: error_count reached 10, aborting.
Sending /home/kozai/cms_proj/uniflash_img/sbl_uart_uniflash.release.hs_fs.tiimage:   0%|                                                         | 2/329295 [00:00<1:09:56, 78.47bytes/s]
[ERROR] XMODEM send failed, no response OR incorrect response from EVM OR cancelled by user,
Power cycle EVM and run this script again !!!

@Ubuntu:~$ ./uart_uniflash_image.sh                                                                                                                                  

Parsing config file ...
Parsing config file ... SUCCESS. Found 2 command(s) !!!

Executing command 1 of 2 ...
Found flash writer ... sending /home/kozai/cms_proj/uniflash_img/sbl_uart_uniflash.release.hs_fs.tiimage
Sent flashwriter /home/kozai/cms_proj/uniflash_img/sbl_uart_uniflash.release.hs_fs.tiimage of size 329295 bytes in 30.09s.                                                               

Executing command 2 of 2 ...
Command arguments : --operation=flash-phy-tuning-data
Sending flash-phy-tuning-data_command:   0%|                                                                                                                   | 0/32 [00:00<?, ?bytes/s]^C
[ERROR] XMODEM send failed, no response OR incorrect response from EVM OR cancelled by user,
Power cycle EVM and run this script again !!!
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨、Toshiki、

    我在里面,请允许我一些时间。

    您能否共享您正在用于闪存的脚本?

    此致、

    Vinit

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

    尊敬的 Vinit:

    我正在使用 uart_uniflash 运行脚本 (cfg)、如下面所示。

    #-----------------------------------------------------------------------------#
    #                                                                             #
    #      DEFAULT CONFIGURATION FILE TO BE USED WITH THE FLASHWRITER SCRIPT      #
    #                                                                             #
    #-----------------------------------------------------------------------------#
    #
    # By default this config file,
    # - points to pre-built flash writer, bootloader for this EVM
    # - The application image points to relative path of the ipc rpmsg linux application image for this EVM
    #   - Make sure this application is built before running this script
    # - You can customized this config file to point to your own bootloader and/or application images
    # - You can use --operation=flashverify if you just want to verify the flash contents and not flash the file.
    #
    # Flash command : python uart_uniflash.py -p {name of your main UART com port} --cfg={path to your edited config file}
    #
    
    --flash-writer=/home/kozai/proj/uniflash_img/sbl_uart_uniflash.release.hs_fs.tiimage
    
    # Program the OSPI PHY tuning attack vector
    --operation=flash-phy-tuning-data
    
    # Now send one or more files to flash or flashverify as needed. The order of sending files does not matter
    # Hsm binary
    --file=/home/kozai/ti/ti-processor-sdk-rtos-j722s-evm-11_01_00_04/mcu_plus_sdk_j722s_11_01_00_15/tools/boot/hsm_bin/hsm-demo-firmware-j722s-hs-fs.bin --operation=flash --flash-offset=0x80000
    
    # MulticoreApp
    --file=/home/kozai/proj/linuxAppimageGen_tr/board/j722s-evm/linux.appimage.hs_fs --operation=flash --flash-offset=0xC0000
    
    # Flash U-Boot.img
    --file=/home/kozai/ti/ti-processor-sdk-rtos-j722s-evm-11_01_00_04/mcu_plus_sdk_j722s_11_01_00_15/tools/boot/hlos_prebuilt/j722s-evm/linux/u-boot.img --operation=flash --flash-offset=0x280000
    
    # When sending bootloader make sure to flash at offset 0x0. ROM expects bootloader at offset 0x0
    --file=/home/kozai/proj/sbl_ospi_hlos/j722s-evm/wkup-r5fss0-0_nortos/ti-arm-clang/sbl_ospi_hlos.release.hs_fs.tiimage --operation=flash --flash-offset=0x0


    此致、

    Toshiki

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

    嗨、Toshiki、

    您使用的是哪个版本的 Uniflash?

    此致、

    Vinit

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

    尊敬的 Vinit:

    正在使用 ti-processor-sdk-j722s_11_01_00_15 中包含的 UART Uniflash 工具 (uart_uniflash.py)(MCU+ SDK 版本 11.01.00.15)。

    此致、

    Toshiki

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

    嗨、Toshiki、

    我承认并会尽快回复您。

    感谢您的耐心。

    Vinit

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

    嗨、Toshiki、

    定制电路板上有什么闪存? 它与 EVM 相同吗?

    此致、

    Vinit

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

    尊敬的 Vinit:

    是的、我们在定制电路板上的闪存器件型号与 EVM 相同。

    此致、

    Toshiki

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

    嗨、Toshiki、

    感谢您耐心等待。

    您能否确认用于刷写的端口未在其他位置打开?

    此外、在 UART 引导模式下、检查您使用的端口是否每 2-3 秒获取一次“C",“,以、以验证是否将正确而有效的端口用于刷写? 您可以使用 minicom 来执行此操作。  

    此致、

    Vinit

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

    尊敬的 Vinit:

    我们已确认在 TeraTerm 中使用的端口每 2-3 秒收到一个字符“C"。“。

    此致、

    Toshiki

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

    嗨、Toshiki、

    TI 硬件工程师是否对定制波特图进行了验证?

    此外、定制电路板上的 OSPI NOR 闪存与 EVM 相同、是 S28HS512TGABHM01、我是对吗?

    定制电路板上的 DDR 是否与 EVM 相同? 背后的原因是、如果更改了 DDR、则需要修改 DDR 配置、并最终必须修改 SBL、以便使此处的刷写工作。

    此致、

    Vinit

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

    嗨、Toshiki、

    请执行以下步骤以了解问题所在、

    我们不使用 UNIFLASH、而是尝试仅通过 UART 引导模式发送映像、然后如果在 SOC 上引导 U-boot、这意味着此处不存在 DDR 配置问题。

    之后、为了测试闪存是否正常工作、在 U-boot 阶段 运行“SF Help“命令、您将看到一系列可以运行的命令、运行 SF 更新或任何命令、如果运行正常、则 OSPI 闪存正常工作。

    请告诉我 可以取得什么进展。

    此致、

    Vinit

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

    尊敬的 Vinit:

    定制电路板上的 OSPI NOR 闪存与 EVM 上使用的 OSPI NOR 闪存 (S28HS512TGABHM01) 相同、并且 DDR 器件也相同 (MT53E2G32D4DE-046 AUT:C)、我们假设无需修改配置。

    我们使用 AppImage 而非 U-Boot 执行了该过程。 在这种情况下、传输成功加载到 EVM 上、但在定制电路板上、尽管传输成功完成、但加载阶段发生了错误。
    基于这种行为、假设 LPDDR4 写入操作(→DDR)正常工作是否合理、而读取操作可能存在问题(←DDR)?
    此外、如果在不使用 U-Boot 的情况下无法正确评估这一点、您能否建议您采用一种仅使用 UART 引导模式发送映像而不依赖 UNIFLASH 的方法?

    本试验的详细信息如下。
    ・Ω EVM
    kozai@VMUbuntu:~/cms_proj$ ./uart_bootloader_uboot_img.sh 
    
    Parsing config file ...
    Parsing config file ... SUCCESS. Found 2 command(s) !!!
    
    Executing command 1 of 2 ...
    Found the UART bootloader ... sending /home/kozai/cms_proj/uniflash_img/sbl_uart.release.hs_fs.tiimage
    Sent bootloader /home/kozai/cms_proj/uniflash_img/sbl_uart.release.hs_fs.tiimage of size 300111 bytes in 31.08s.    
    
    Executing command 2 of 2 ...
    Command arguments : --file=/home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs --operation=run
    Sending /home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs: 129654bytes [00Sending /home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs: 129654bytes [00Sending /home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs: 129655bytes [00Sending /home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs: 129656bytes [00Sending /home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs: 129657bytes [00Sending /home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs: 129658bytes [00                                                                                                                    Sent /home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs of size 128742 bytes in 13.63s.
    [STATUS] Application load SUCCESS !!!
    
                                                                                                                        
     Sent End Of File Transfer message of size 4 bytes in 3.1s.
    
    All commands from config file are executed !!!
    Connect to UART in 5 seconds to see logs from UART !!!
    
    ・定制电路板
    kozai@VMUbuntu:~/cms_proj$ ./uart_bootloader_uboot_img.sh 
    
    Parsing config file ...
    Parsing config file ... SUCCESS. Found 2 command(s) !!!
    
    Executing command 1 of 2 ...
    Found the UART bootloader ... sending /home/kozai/cms_proj/uniflash_img/sbl_uart.release.hs_fs.tiimage
    Sent bootloader /home/kozai/cms_proj/uniflash_img/sbl_uart.release.hs_fs.tiimage of size 300111 bytes in 29.52s.                                                                 
    
    Executing command 2 of 2 ...
    Command arguments : --file=/home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs --operation=run
    Sent /home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs of size 128742 bytes in 13.06s.                                                 
    [STATUS] ERROR: Application load FAILED !!!
    
                                                                                                                                                                                     
     Sent End Of File Transfer message of size 4 bytes in 3.09s.
    
    All commands from config file are executed !!!
    
    ・下面是 uart_bootloader.py 所用 cfg 文件的内容。
    # First point to sbl_uart binary, which function's as a server to receive application images of other cores through uart
    --bootloader=/home/kozai/cms_proj/uniflash_img/sbl_uart.release.hs_fs.tiimage
    
    # MulticoreApp
    --file=/home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/hello_world.release.appimage.hs_fs --operation=run

    此致、

    Toshiki

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

    嗨、Toshiki、

    要使用 UART 引导模式运行 U-boot、

    请参阅 有关刷写技术的此文档、请参阅名为“UART 引导模式“的部分、您将获得常见问题解答以及添加详细步骤。

    此致、

    Vinit

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

    尊敬的 Vinit:

    谢谢你。 提及该文档时、我将尝试运行 U-Boot。
    顺便说一下、如前所述、认为该问题可能与 LPDDR4 读取访问问题有关是否正确?

    此致、

    Toshiki

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

    嗨、Toshiki

    顺便说一下、如前所述、认为该问题可能与 LPDDR4 读取访问问题有关吗?

    我们不确定这一点。 但使用 U-Boot、我们会确保这一点。

    此致、

    Vinit

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

    尊敬的 Vinit:

    我们能够成功地写入第二个具有相同配置的定制电路板上的闪存、我当时正在开发该电路板、这导致了我的响应延迟。 很抱歉晚才回复。

    为了找出根本原因、我在第一块电路板上重新检查了问题。
    当尝试在 UART 引导模式下引导 U-Boot 时、该过程会在传输二进制数据的过程中停止、如附加映像中所示。

    我尝试了这个过程三次,在所有的情况下,转移停止在完全相同的点。

    我要遵循的过程基于以下链接中描述的步骤:
    演示文稿标题

    步骤如下:

    • 使用 XMODEM 写入 tiboot3-j722s-hs-fs-evm.bin
    • 使用 Ymodem 写入 tispl.bin
      →此过程在此步骤停止
    • 写入 u-boot.img(未达到此步骤)

    在第二块电路板上、通过执行完全相同的过程可以成功执行 U-Boot。

    鉴于此问题仅发生在第一块电路板上、请您就可能的原因或应检查的其他要点提供建议。

    此致、

    Toshiki

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

    嗨、Toshiki、

    我们能够使用相同的配置成功写入第二个定制电路板上的闪存、我正在开发该电路板、这导致了我的响应延迟。 很抱歉、您稍后回复。

    您是说对于与电路板相同的第二个电路板、uniflash 刷写(我们在第一个电路板上遇到的实际问题)工作正常还是使用 UART 引导加载程序的 U-boot 工作正常?

    此致、

    Vinit

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

    尊敬的 Vinit:

    在第二个电路板上、两个操作都成功。 但是、由于我们尚未确定第二块电路板成功运行的根本原因、因此我们想重点解决第一块电路板上的问题。
    在第一块电路板之前、我们还有一个原型板、该板上也出现了同样的问题。 因此、此问题可重现、并且不限于单个电路板。

    此致、

    Toshiki

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

    嗨、Toshiki、

    很抱歉、延迟的回复。

    我们在我们这边讨论这个问题、但这个问题似乎是特定于我们的主板、因为如果这是软件问题、它会出现在所有主板上、但在这种情况下不是这样。

    我们希望您首先联系您的内部硬件团队、以 检查可正常工作的电路板和不可正常工作的电路板之间的差异。

    此致、

    Vinit