• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 375 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM2431: Application failed to load when trying to debug with CCS

Hayato Waki
Prodigy 130 points
Part Number: AM2431
Other Parts Discussed in Thread: UNIFLASH, TMDSEMU110-U

Dear person in charge.

We use a custom board with AM2431.

Flash write with JTAG uniflash using XDS110 from CCS.

Application failed to load when trying to debug with CCS.

Is the debugging operation procedure incorrect? What is the cause?


MAIN_Cortex_R5_0_0: Trouble Writing Memory Block at 0x70180190 on Page 0 of Length 0x14b8: (Error -1065 @ 0x70181190) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.6.0.00172)
MAIN_Cortex_R5_0_0: File Loader: Verification failed: Target failed to write 0x70180190
MAIN_Cortex_R5_0_0: GEL: File: C:\ti\mcu_plus_sdk_am243x_08_03_00_18\examples\cpu_ti\test_app\Debug\test_app_am243x.out: Load failed.

<Procedures performed>

1.  Script execution of load_dmsc_hsfs.js from CCS to initialize SOC. (Boot mode=Dev-boot(JTAG))

2. Connect target.

3. Load sbl_jtag_uniflash_am243x-evm_r5fss0-0_nortos_ti-arm-clang.out and write sbl_ospi and application to OSPI Flash.(Boot mode=Dev-boot(JTAG))

4. Loading application XX.out from Load Program.(Boot mode=xSPI)

Error message occurs. By the way, XX.out of sbl_ospi could be loaded and debugged.

The memory access error occurred in MSRAM. The same error occurred when the section map was assigned to DDR memory.

Best Regards,

Hayato Waki.

  • 0
    TI__Expert 7245 points

    Hello Hayato, 

    I have a few questions that I need clarity on before I can help you further:

    1. Can you share the schematic for reference? or at least the sections that show PORz, BOOT configuration, and JTAG?
    2. How are you connecting via JTAG? If you are using an external emulator, which probe are you using?
    3. Can you confirm JTAG connection by clicking the "Test Connection" button within the target configuration in CCS?
    4. Are you using a GP or HS-FS device? If the Device Revision is "B" or a subsequent letter then the device is HS-FS. If you are using an HS FS device, have you read through the HS-FS Migration Guide? https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/09_01_00_41/exports/docs/api_guide_am243x/HSFS_MIGRATION_GUIDE.html

    Regards,

    Erik

  • 0 in reply to Erik Friedel
    Prodigy 130 points

    Hello Erik,

    >>1. Can you share the schematic for reference? or at least the sections that show PORz, BOOT configuration, and JTAG?
    PORz is set at a high level. It is not in a reset state.

    The boot settings are configured as follows.
    The xSPI and Dev Boot modes are switched by B3.

    15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
    Reserved Reserved Backup Boot ModeConfig Backup Boot Mode Primary Boot Mode Config Primary Boot Mode PLL Config 　
    X X 1 1 0 1 0 0 0 1 1 1 0 0 1 1 xSPI
    X X 1 1 0 1 0 0 0 1 1 1 1 0 1 1 Dev boot

    JTAG is connected as follows.There seems to be no FAIL.


    >>2. How are you connecting via JTAG? If you are using an external emulator, which probe are you using?
    We are using an external emulator, TMDSEMU110-U.

    >>3. Can you confirm JTAG connection by clicking the "Test Connection" button within the target configuration in CCS?
    The log is shown below.

    [Start: Texas Instruments XDS110 USB Debug Probe_0]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

    [Result]


    -----[Print the board config pathname(s)]------------------------------------

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioxds110.dll'.
    The library build date was 'Dec 8 2021'.
    The library build time was '11:16:32'.
    The library package version is '9.6.0.00172'.
    The library component version is '35.35.0.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '5' (0x00000005).
    The controller has an insertion length of '0' (0x00000000).
    This utility will attempt to reset the controller.
    This utility has successfully reset the controller.

    -----[Print the reset-command hardware log-file]-----------------------------

    The scan-path will be reset by toggling the JTAG TRST signal.
    The controller is the XDS110 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for XDS110 features.
    The controller cannot monitor the value on the EMU[0] pin.
    The controller cannot monitor the value on the EMU[1] pin.
    The controller cannot control the timing on output pins.
    The controller cannot control the timing on input pins.
    The scan-path link-delay has been set to exactly '0' (0x0000).

    -----[Perform the Integrity scan-test on the JTAG IR]------------------------

    This test will use blocks of 64 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG IR Integrity scan-test has succeeded.

    -----[Perform the Integrity scan-test on the JTAG DR]------------------------

    This test will use blocks of 64 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG DR Integrity scan-test has succeeded.

    [End: Texas Instruments XDS110 USB Debug Probe_0]

    >>4. Are you using a GP or HS-FS device? If the Device Revision is "B" or a subsequent letter then the device is HS-FS. If you are using an HS FS device, have you read through the HS-FS Migration Guide? 
    We are using a HS-FS device. We have also read the Migration Guide.
    What causes memory access errors?

    Best Regards,

    Hayato Waki.

     

  • +1 in reply to Hayato Waki
    TI__Mastermind 26145 points

    Hi ,

    In case of dev boot mode (or when you are using load_dmsc_hsfs.js) the last 512KB of the SRAM memory is reserved or firewalled by the ROM and this is a known issue. I don't think we have a valid solution for this till date, but I will try to gather a little more information on this to confirm if this is really fixable or not.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Prodigy 130 points

    Hi Mr. Aakash

    Thank you for your reply.
    sbl_ospi.Debug.hs_fs.tiimage wasn't written to Flash correctly. Or there was a prolem with sbl_ospi.Debug.hs_fs.tiimage.
    I wrote the appropriate sbl_ospi to Flash and the problem was solved.

    Best Regards,
    Hayato Waki