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.

TMDS243GPEVM: Running MCU SDK examples hang in Sciclient_waitForMessage

Part Number: TMDS243GPEVM

After successful DDR init (when first connected to the M3 core), I was able to load complex examples to the R5_0_0 - the "enet_lwip" and also the "ethercat_slave_simple_demo_am243x-evm".

Both of them stop at Sciclient_waitForMessage() function, calling CSL_REG32_RD_RAW(). 

As far as I can see in the SW, the sciclient is intended to communicate with the DMSC (the M3 core). So I wonder if I need to do some additional steps after the DDR4 no-ECC init? I tried to just connect to the M3 - without running it - in this case, the DDR init is successful but when I run the R5 it hands in the Sciclient_waitForMessage().

No matter if I run the M3 core and then run the R5, or I keep the M3 core only connected and then run the R5, I come to the point where the system hands inside the PowerClock_init(), precisely in the Sciclient_waitForMessage(). I see this by pausing the R5 core. If I then pause the M3, I see this state:

Edit: all this is done with flashed "SBL null" and QSPI boot mode:

Starting NULL Bootloader ... 

DMSC Firmware Version 21.5.0--v2021.05 (Terrific Llam
DMSC Firmware revision 0x15
DMSC ABI revision 3.1

INFO: Bootloader_runCpu:147: CPU r5f1-0  is initialized to 800000000 Hz !!!
INFO: Bootloader_runCpu:147: CPU r5f1-1 is initialized to 800000000 Hz !!!
INFO: Bootloader_runCpu:147: CPU m4f0-0 is initialized to 400000000 Hz !!!
INFO: Bootloader_loadSelfCpu:199: CPU r5f0-0 is initialized to 800000000 Hz !!!
INFO: Bootloader_loadSelfCpu:199: CPU r5f0-1 is initialized to 800000000 Hz !!!
INFO: Bootloader_runSelfCpu:216: All done, reseting self ...

  • Hello,

    The flashed SBL Null initializes the DDR so you do not need run DDR init from within CCS. What happens if you follow the sequence below? Do you still observe the same behavior?

    1. Connect and power on your board in QSPI boot mode with SBL NULL flashed.

    2. Launch the CCS debug session and connect to the R5 core (do not connect to the M3).

    3. Load and run your program.

    Regards,
    Sahin

  • If I follow your sequence, I could load simple examples - HelloWorld and i2c_led_blink. I can cycle through them multiple times (with a CPU reset before every load).

    But if I try ethercat_slave_simple_demo or enet_lwip_cpsw, the load fails - it seems to run - the progress got loading PT_LOAD[2] - from 0 to 524640 at 0x7000100. The progress completes (reaches 524640) and there starts a second "progress" of something PT_LOAD[3] at 0x70081180 with size of about 136400. There is a third load of about 8K -  that is too short to read. It finishes and then error message comes:

    MAIN_Cortex_R5_0_0: Trouble Writing Memory Block at 0x84000000 on Page 0 of Length 0x21c0: (Error -1065 @ 0x84001000) 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.4.0.00129) 
    MAIN_Cortex_R5_0_0: File Loader: Verification failed: Target failed to write 0x84000000
    MAIN_Cortex_R5_0_0: GEL: File: C:\Users\******\workspace_v10\ethercat_slave_simple_demo_am243x-evm_r5fss0-0_freertos_ti-arm-clang\Debug\ethercat_slave_simple_demo_am243x-evm_r5fss0-0_freertos_ti-arm-clang.out: Load failed.

    At this point, if I issue "CPU reset", I can load successfully again the Hello world project, or the i2c_led_blink - so the debugger is still connected and the CPU responds just like before failure.

    I observe the same behavior with other "big" projects - eip. I've got similar behavior in the Cloud variant of the CCS last week - there I was able to load and debug those simple examples, but an attempt to debug the complex ones failed. I point this out because there is nothing to set up in the Cloud IDE - all debug settings are in the projects and should work out-of-the-box?

  • Hi Krasi,

    The address 0x84000000 is DDR so this issue seems DDR related. I believe the helloworld and i2c_led_blink examples do not use DDR but need to confirm.

    I'm going to try to reproduce this on my end - I will follow up with a reply on Friday.

    Regards,
    Sahin

  • Thank you, Sahin - I also planned to check the linker scripts and compare working vs. non-working examples to identify specific resources that are used in the non-working ones.

  • Hi Krasi,

    I was able to reproduce this issue on my board. I'm working on root-causing and will follow-up early next week.

    Regards,
    Sahin

  • I was wondering if there is any progress on this issue? I could not solve it by myself (checking the linker scripts) so I hope that you have sorted it out.