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.

MCU-PLUS-SDK-AM243X: Problem to upload profinet code

Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: UNIFLASH

HI team,

We are using the "profinet rt rgmii demo example in MCU-PLUS-SDK-AM243X Version 08_06_00_48", and it builds perfectly when we upload the code to the AM243X-evm board. We get the following error on the console:.

MAIN_Cortex_R5_0_0: Trouble Writing Memory Block at 0x80000000 on Page 0 of Length 0x7ff0: (Error -1170 @ 0x80001000) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.13.0.00201)

MAIN_Cortex_R5_0_0: File Loader: Verification failed: Target failed to write 0x80000000

MAIN_Cortex_R5_0_0: GEL: File: C:\Users\Admin\workspace_v12_2\profinet_device_rt_rgmii_demo_am243x-evm_r5fss0-0_freertos_ti-arm-clang\Debug\profinet_device_rt_rgmii_demo_am243x-evm_r5fss0-0_freertos_ti-arm-clang.out: Load failed.

MAIN_Cortex_R5_0_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.13.0.00201)

MAIN_Cortex_R5_0_0: Unable to determine target status after 20 attempts

MAIN_Cortex_R5_0_0: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

Please help me out.

--

Thanks & Regards,

Divyesh Patel

  • Hi Divyesh Patel,

    MAIN_Cortex_R5_0_0: File Loader: Verification failed: Target failed to write 0x80000000

    Seems like there is an issue with the DDR initialization seeing the above log

    Q1. What bootmode are you using?

    Incase you have SBL null flashed to your device and the bootmode is OSPI, when you reset your device, the DDR will be initialized by the SBL. If not, you will have to use the correct gel scripts to initialize the DDR manually before loading the application to your AM243x. 

    when we upload the code to the AM243X-evm board

    Q2. Are you flashing the .appimage file to the AM243x EVM using the uart_uniflash.py file or using CCS to side-load the .out file?

    I would recommend you to try it as follows: 

    1. Flash SBL null to the AM243x-EVM (ignore if already done)

    2. Power reset your device

    3. Connect to the desired core and Load your application (.out) file

    Please try the above mentioned and let me know if it works.

    Regards,

    Shaunak

  • Thanks for your reply.

    We also run other Ethernet examples like ethercat and ethernetip adapter, all of which work perfectly.

    What boot mode are you using?
                  We use NOBOOT MODE.
       
    Are you flashing the.appimage file to the AM243x EVM using the uart_uniflash.py file or using CCS to side-load the.out file?
                  We flash the code using CCS.

  • Hi Divyesh Patel,

    We also run other Ethernet examples like ethercat and ethernetip adapter, all of which work perfectly.

    This is because the mentioned examples don't require the DDR, so DDR being initialized or not wouldn't matter here. Profinet RT RGMII demo uses DDR.

    There are 2 options to overcome this error here:

    1. If you want to use NOBOOT mode, then manually run the gel script to initialize the DDR. Then once the DDR is initialized, side load the application and run it. You can find the same by launching your .ccxml target configuration, connecting to the desired core and on the top pane, select Scripts -> AM243x_DDR Initialization.

    2. Switch to QSPI boot mode and flash SBL null to the AM243x EVM device. Then reset the board. This way, everytime the SBL will take care of the initialization of the DDR and you can directly side load your application without having to worry about running the gel script.

    Either way it will work, but following the 2nd one would be easier and faster for future development as well. The 2nd option is what I would recommend, but you can try either one.

    Regards,

    Shaunak