• State
  • Replies 10 replies
  • Subscribers 34 subscribers
  • Views 255 views
  • Users 0 members are here
Support feedback
Options
Options
Related

UNIFLASH: Regarding Verification Methods Using the UniFlash CLI

ATSUKI IMADA
Prodigy 10 points

Part Number: UNIFLASH
Other Parts Discussed in Thread: AM263P4, , SYSCONFIG

We are currently developing a custom board using the AM263P4 and are in the process of setting up a mass production line.

Until now, since we were in the development phase, we have been using the GUI version of UniFlash. However, the GUI version does not provide a verification function after programming. During our investigation, we learned from the Quick Start Guide that the CLI version supports verification after programming.

Based on this information, we converted the project we had been using into a CLI-based workflow and executed it. As a result, the following output was displayed:

info: Cortex_R5_0: Program verification successful for Multiple Files
Success

From this message, we understand that the verification has been completed successfully. However, we would like to know how the verification is actually performed, and we would appreciate it if you could provide a more detailed explanation of the verification mechanism.

The details of our environment and the command used are as follows:

  • MCU: AM263P4
  • UniFlash Version: 9.3.0.5401

Command used:

dslite --mode flash 
       -c user_files/configs/AM263Px_ZCZ_C.ccxml 
       -l user_files/settings/generated.ufsettings 
       -s VerifyAfterProgramLoad="No verification" 
       -e 
       -f 
       -v 
       "user_files/images/xxx.tiimage,0x60000000" 
       "user_files/images/yyy.appimage,0x60081000"

(Note: xxx and yyy represent the actual program file names.)

In addition, although it may be unrelated to the above, we sometimes observe behavior in which the program does not seem to be written correctly unless the programming operation is performed multiple times, both when using the GUI and the CLI.
Are there any recommended methods to identify the root cause of this issue, or known solutions to resolve it?

Thank you very much for your support.

  • 0
    TI__Intellectual 1150 points

    Hello,\


    I have received your query. Please give me sometime to take a look into this. I will try to respond by this Friday. Thanks for your patience.

    Best Regards,
    Aswathi

  • 0 in reply to Aswathi R
    Prodigy 10 points

    Hello, Aswathi

     

    Thank you for your response.
    This matter is quite urgent, so I would really appreciate it if you could get back to me as soon as possible.
    I apologize for the inconvenience, and thank you in advance for your understanding.

     

    Best regards,
    Imada
  • 0 in reply to ATSUKI IMADA
    TI__Expert 6825 points

    Hello, 

    In uniflash CLI tool, the program verification feature is not valid for AM26x devices. In UniFlash CLI documentation, this is mentioned because, the documentation is generic to the tool. For AM26x devices, this is just a dummy print.

    For verification, please use the sbl_jtag_uniflash example from MCU PLUS SDK. This tool can program and verify both application and xip files.

    Tool Link: mcu_plus_sdk_am263px_11_01_00_19\examples\drivers\boot\sbl_jtag_uniflash

    Thanks & Regards,

    Aswin

  • 0
    Prodigy 10 points

    Hello Aswin,

    Thank you very much for your message.

    We understand that the program verification feature in the UniFlash CLI tool is not valid for AM26x devices.

    Regarding the usage of the sbl_jtag_uniflash you mentioned, we would like to confirm the intended workflow.
    Is the sbl_jtag_uniflash example supposed to be used from CCS, or is it intended to be built and used via CLI?

    The reason we ask is that we are considering using this tool in our mass production process, where we would like to program the software together with the SBL. Preferably, we would like to operate this process using CLI-based tools, if possible.

    Could you please advise on the assumed usage environment for sbl_jtag_uniflash, and whether there are any recommended methods or workflows to use it (or alternative tools) in a CLI-based mass production setting?

    We appreciate your guidance on this matter.

    Best regards,
    Atsuki Imada

  • 0 in reply to ATSUKI IMADA
    TI__Expert 6825 points

    Hello Atsuki Imada,

    The tool is intended to be used from CCS itself. Let me check if there is any way how this can be used via CLI. I will check this and get back to you.

    Thanks & Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    TI__Expert 6825 points

    Hello Atsuki Imada,

    May I know which SDK you are on? From SDK version 11.0, only mcelf images are supported.

    In pre 11.0 vSDK, only app image is supported. XIP image verification is also possible only in 11.0 SDK. So, if you are using app image then xip image verification would not be possible.

    For a flasher utility which satisfies your requirements,

    1. The sbl_jtag_uniflash example needs to modified so that it directly flashes the SBL and application images. Currently it waits for user prompt. This wait needs to be removed.

    2. A DSS script needs to be written which will load the sbl_Jtag_uniflash's .out file into the memory.

    3. Once the image is loaded, the loadRaw() commands need to be run in the scripting console to load the SBL and application image into RAM so that it is accessible by the sbl_jtag_unifflash running in the SoC. This needs to be done because the flasher application once it is running in the SoC cannot access local files in the system.

    The DSS Script mentioned in Step 2 needs to handle the loadRaw() command in Step3 as well. Let me know if this method is acceptable and the SDK version?

    ┌─────────────────────────────────────────┐
│ 1. Load SBL JTAG Uniflash via JTAG      │
│    - Connects via JTAG/debugger         │
│    - Loads uniflash app to RAM          │
│    - Displays menu on serial console    │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│ 2. Load Image into RAM                  │
│    - Provided file path & flash offset  │
│    - Execute loadRaw in CCS console     │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│ 3. Flash/Verify Operation               │
│    - SBL processes image from RAM       │
│    - Writes to external flash           │
│    - Verifies data integrity            │
│    - Returns status                     │
└─────────────────────────────────────────┘

  • 0
    Prodigy 10 points

    Hello Aswin,

    The SDK version currently used in our development is 9.2.0.56.
    We are planning to upgrade to SDK version 11.0.0.19 in the future; however, for production shipment, we do not plan to program an XIP image. Instead, we intend to program only the application image (mcelf image).

    To evaluate the procedure you proposed, we believe that the first step is to verify whether we can successfully program our application using sbl_jtag_uniflash.

    Our application program size is nearly twice as large as the sample. In this case, would it be sufficient to modify only the FILE_MAX_SIZE parameter to match the larger size in order to run the sample correctly?
    Additionally, is it recommended that the size allocated here be exactly the same as the program size, especially when there is no unused memory space available after this region?

    Best regards,
    Atsuki Imada

  • 0 in reply to ATSUKI IMADA
    TI__Expert 6825 points

    Hi Atsuki Imada,

    The FILE_MAX_SIZE macro needs to be increased. Also the same change needs to be done in the linker script so that the file will be accommodated.

    Thanks & Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    Prodigy 10 points

    Hello Aswin,

    I apologize for the delayed response.

    I tested the setup using a custom board (MCU: AM263P4, FLASH: IS25LX128) and CCS 12.8.1.
    As a result, I encountered the following issues and would like to ask for your confirmation.

    ① The program file is too large to write

    The size of the software to be written to the custom board is 4,075,548 bytes.
    I tried modifying the Memory Region MSRAM_ Region Size to 0x003E3700, but I received the following error:
    "Size can't be greater than 3145728 B",
    so I was unable to change the setting.

    Is there any way to write such a large file?

    ② What is the base address? What does the offset mean?

    I understand that sbl_jtag_uniflash loads the software intended for FLASH into RAM, and then writes it to FLASH.

    At that time, an offset is specified, but what address is used as the base reference?
    Is it the start address of FLASH (0x60000000), or something else?

    ③ It uses block writing, but I want sector writing (write to 0x81000)

    In this case, I intend to write the software starting from FLASH address 0x60081000.
    However, the sample code uses block-based writing rather than sector-based writing, so it cannot be written as intended.
    (It seems that only 0x0 or 0x020000 can be specified.)

    Is there any sample code that supports sector-based writing?

    ④ The unmodified sample code did not work properly

    After completely erasing the FLASH, I deployed the code to RAM via CCS debug and attempted to run it,
    but sbl_jtag_uniflash did not start on the custom board RAM.

    However, when using a custom board with the sample SBL already written,
    sbl_jtag_uniflash started as expected.

    Does sbl_jtag_uniflash require an SBL in order to run?

    Additionally, before using sbl_jtag_uniflash, I wrote the sample SBL and verified it using a UniFlash dump.
    Then I wrote the same SBL using sbl_jtag_uniflash and checked it again with a dump.
    However, the area where the sample SBL had been placed was filled with zeros,
    and the SBL did not boot.

    Do you have any suggestions to resolve this issue?

    If possible, I would appreciate your response by June 8.

    Thank you for your support.

    imada

  • 0 in reply to ATSUKI IMADA
    TI__Expert 6825 points

    Hello,

    ATSUKI IMADA said:
    I tried modifying the Memory Region MSRAM_ Region Size to 0x003E3700, but I received the following error:
    "Size can't be greater than 3145728 B",
    so I was unable to change the setting.

    Can you please tell me from where this message is coming. Is this coming from sysconfig. Also I assume MSRAM is the on chip RAM region. The device does not have this much RAM region. The file is more than 4MB.

    ATSUKI IMADA said:

    ② What is the base address? What does the offset mean?

    I understand that sbl_jtag_uniflash loads the software intended for FLASH into RAM, and then writes it to FLASH.

    At that time, an offset is specified, but what address is used as the base reference?
    Is it the start address of FLASH (0x60000000), or something else?

    I assume the offset is regarding this offset as shown in the picture

    Yes this is the offset in flash, i.e the offset from the flash base address which in this case is 0x6000_0000

    ATSUKI IMADA said:

    ③ It uses block writing, but I want sector writing (write to 0x81000)

    In this case, I intend to write the software starting from FLASH address 0x60081000.
    However, the sample code uses block-based writing rather than sector-based writing, so it cannot be written as intended.
    (It seems that only 0x0 or 0x020000 can be specified.)

    Is there any sample code that supports sector-based writing?

    May I know what is the operationTypeAndFlags used in thie case. There is the BOOTLOADER_UNIFLASH_OPTYPE_FLASH_SECTOR paramater present

    ATSUKI IMADA said:

    ④ The unmodified sample code did not work properly

    After completely erasing the FLASH, I deployed the code to RAM via CCS debug and attempted to run it,
    but sbl_jtag_uniflash did not start on the custom board RAM.

    However, when using a custom board with the sample SBL already written,
    sbl_jtag_uniflash started as expected.

    Does sbl_jtag_uniflash require an SBL in order to run?

    Additionally, before using sbl_jtag_uniflash, I wrote the sample SBL and verified it using a UniFlash dump.
    Then I wrote the same SBL using sbl_jtag_uniflash and checked it again with a dump.
    However, the area where the sample SBL had been placed was filled with zeros,
    and the SBL did not boot.

    Do you have any suggestions to resolve this issue?

    ATSUKI IMADA said:
    Does sbl_jtag_uniflash require an SBL in order to run?

     No it does not require any sample SBL. Have you confirmed if the OSPI and Flash settings are in accordance with the custom board? This can be loaded directly from CCS.

    Can you please share the observation when loading the sbl_jtag_uniflash example from CCS?

    ATSUKI IMADA said:
    Then I wrote the same SBL using sbl_jtag_uniflash and checked it again with a dump.
    However, the area where the sample SBL had been placed was filled with zeros,
    and the SBL did not boot.

    This would mostly point towards some flash communication issue. This could be related to OSPI Flash configuration in sysconfig. If I remember correctly, KHI has tried this example on custom board from previous debugs.

    Thanks & Regards,
    Aswin