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.

AM2434: Dual core debug single-step fail between two core fail.

Part Number: AM2434
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hello Specialists,

I was using a AM243x-LP demo-board to try to debug MCU+SDK10.00 example by loading hello_world's xxx.out into R5F_0_0 and  by loading gpio_led_blink's yyy.out into R5F_0_1.

First step I downloaded yyy.out into R5F_0_1 and the second step I downloaded xxx.out into R5F_0_0, and then I tried to do single step on R5F_0_0 hello_world main.c and it work ok. After that I click inside the "Debug" window on the R5F_0_1 gpio_led_blink core and then I click single step, but this time single step couldn't work on R5F_0_1 gpio_led_blink main.c.

It seemed that I could only successfully use single step on the second core to be loaded with xxx.out, and the first core loaded with  yyy.out couldn't do single step properly.

Is it the way I switch from one core to another core to be wrong?

Please help. 

Thank you very much.

Best Regards,  JasonChiu.

  • Hi Mr. Jason,

    Thanks for your query.

    After that I click inside the "Debug" window on the R5F_0_1 gpio_led_blink core and then I click single step, but this time single step couldn't work on R5F_0_1 gpio_led_blink main.c.

    Can you please tell what issue are you facing? Are there any error logs?

    Can you please share the screenshot with us?

    Regards,

    Tushar

  • Hello Mr. Tushar,

    Thank you very much for quick reply to my question.

    Before I capture error message for you, please help this?

    I had a question a few days ago about an instruction on TI website (when you solved my script problem):

    (I was wondering if this was the cause of yesterday's debug mode single-step problem?).

    Would you please help to clarify my question about the TI website instruction? 

    I was not able to comply with that requirement when I try/test SDK example codes.

    Thank you very much.

    Best Regards,   JasonChiu.

  • Hello Mr. Jason,

    These two boot modes (QSPI, DEV) are completely different from each other and follows different ways of SoC initialization.

    The DEV boot mode gives user a option to initialize the SoC using CCS. While the QSPI boot mode uses Flash as a boot media to initialize the SoC.

    To use QSPI boot mode you will need to flash the binaries using UART Uniflash tool and then switch to QSPI boot mode.

    Please follow the steps suggested at EVM_FLASH_SOC_INIT. 

    Regards,

    Tushar

  • Hello Mr. Tushar,

    Thank you very much. You mean when I use CCS to test/debug AM243x-LP with SDK example codes, I need to use DEV BOOT MODE.  My last question failure in debug mode single step operation between 2 cores was using QSPI mode and without running the SOC script. My wrong setting on SW4 BOOT MODE may be the cause of the single-step error. I will test/try later to use DEV BOOT MODE and I will do SoC initialization script before I download two example codes into two cores.

    Thank you very much.

    Best Regards,  Jason Chiu.

  • Hi Mr. Jason,

    You mean when I use CCS to test/debug AM243x-LP with SDK example codes, I need to use DEV BOOT MODE

    You can debug the code through CCS even if you use the QSPI boot mode. The only difference is in DEV boot mode you are initializing the SoC using CCS which is not possible if other boot mode is used.

    I will test/try later to use DEV BOOT MODE and I will do SoC initialization script before I download two example codes into two cores.

    Looking forward to hear from you.

    Regards,

    Tushar

  • Hello Mr. Tushar,

    Thank you very much for clarify the CCS debug operation vs. BOOT MODE.

    I has a question on your previous reply: You said:

    "The only difference is in DEV boot mode you are initializing the SoC using CCS which is not possible if other boot mode is used."

    My question is what is the difference between "I do an initializing on SoC and then to debug 2 cores" and "I couldn't do initializaing on SoC to debug 2 cores"?

    I have another question here: It is on SDK_08_05 HS-FS Migration Guide:

    Since my MCU is HS-FS type, based on the above table, your guides a few days ago, provided to me with DEV-BOOT mode (mandatory): 

    What I don't understand is the difference between the two (1) and (2) below, if I want to do debug single-step on two cores?

    Would you please help to explain them?

    Thank you very much.

    Best Regards,  Jason Chiu.

  • Hello Mr. Jason,

    My question is what is the difference between "I do an initializing on SoC and then to debug 2 cores" and "I couldn't do initializaing on SoC to debug 2 cores"?

    Sorry, I didn't get the question completely.

    Are you trying to figure out what is difference between debugging cores when SoC is initialized v/s SoC not initialized?

    What I don't understand is the difference between the two (1) and (2) below, if I want to do debug single-step on two cores?

    The image shared above shows the difference between GP and HSFS device.

    As in (1) we are talking about bootmode settings when CCS+GEL flow is used.

    And in (2) we are talking about the js script needs to run when CCS+GEL flow is used. 

    Regards,

    Tushar

  • Hello Mr. Tushar, 

    Thank you very much for your answer.

    I got answers for my previous first question: The initialized SoC can make me use the SoC multiple cores more easily. 

    Thank you for answering my second question, but I still could not understand clearly the difference between (1) and (2). Would you please help to elaborate more? 

    Now I only know (1) is related to BOOT MODE and CCS+GEL. I know that my chip is HSFS type and I could only use DEV-BOOT mode now. I don't know what GEL is used in this mode (Is the GEL in this "DEV-BOOT mode" to be different from the GEL in that "CCS+GEL flow js script"?) 

    Since you taugt me to use gmake -s -C examples/drivers/sciclient.....sciclient_ccs_init.release.out to do SoC initialization, I assume that I don't need to run LoadJSFile "C:/ti/mcu_plus_sdk/tools/ccs_load/am243x/load_dmsc_hsfs.js".  My further question was: Why use that example file to do SoC initialization? Can you use other examples to do SoC initialization? If not, would you please help to explain why? If I want to run other examples on that core (R5F_0), can I upload my other examples into that R5F_0 core (as long as I didn't power-off the AM243x-LP)? Or I have to keep that sciclient code in R5F_0 all the time?

    Since document said that user needs to do SoC initialization everytime when power-on the demo-board, I assume that I need to use DEV-BOOT mode and run the "gmake....." every time I power-on the demo-board. Is this assumption correct?  

    Thank you very much. 

    Best Regards,  Jason  Chiu.

  • Hello Mr. Jason,

    I thinks there is some sort of confusion here in understanding the above concept.

    . I know that my chip is HSFS type and I could only use DEV-BOOT mode now

    The HSFS devices can use other boot mode as well like UART, OSPI. The compulsion to stick with DEV boot mode is only for SOC intialization done using CCS.

    But for initializing the SoC using SBL binaries you can use the UART boot mode and then switch to OSPI boot mode to run the application.

    Since document said that user needs to do SoC initialization everytime when power-on the demo-board, I assume that I need to use DEV-BOOT mode and run the "gmake....." every time I power-on the demo-board. Is this assumption correct? 

    When you flash SoC using SBL binaries, you do not need to initialize the SOC each time when you reset or power cycle the EVM. The binaries are flashed to OSPI flash and is used when OSPI boot mode is selected.

    Please refer EVM_FLASH_SOC_INIT for initializing SoC using SBL binaries. 

    Regards,

    Tushar

  • Hi Mr. Jason,

    Why use that example file to do SoC initialization? Can you use other examples to do SoC initialization? If not, would you please help to explain why?

    No, you can't load other examples to do the SoC initialization. This is a special soc initialization example which loads the System Firmware on Cortex M3, sends the sciclient boardcfg to the SYSFW running on M3 and initializes the other cores users to connect and debug. 

    Please refer DRIVERS_SCICLIENT_CCS_INIT.html for details.

    Regards,

    Tushar

  • Hi Mr. Jason,

    If I want to run other examples on that core (R5F_0), can I upload my other examples into that R5F_0 core (as long as I didn't power-off the AM243x-LP)? Or I have to keep that sciclient code in R5F_0 all the time?

    Once the example completes its execution successfully, initialization logs will come on the console and the R5F core will be at reset vector.

    You can now load other applications to the R5F0-0 core and run it.

    Regards,

    Tushar

  • Hello Mr. Tushar, 

    I was not aware of SBL binary to do SoC initialization to be only need to be done once (will not loss with power-on-off. Thank you for telling me this. 

    My impression about doing SoC initialization everytime power-off-on was perhaps only applicable to DEV-BOOT mode to work with CCS:

    Strangely the document above did mention to do SoC initialization whenever there is a power-on-off. 

    Would you please helpt clarify this? 

    Thank you very much.

    Best Regards,   JasonChiu.

  • Hello Mr. Jason,

    When CCS+GEL Flow is used that means, the programmer is directly writing to the SoC's internal memory through JTAG interface using CCS IDE.

    In this method, For HSFS device DEVBOOT mode & for GP device NOBOOT mode is necessary as it tells the SOC that there is no boot media selected for SoC to read image from. The programmer can directly write initialization instructions to SoC memory. When power cycle or reset is done the content is lost and registers values are set to default. So the same initialization process needs to be repeated.

    Please refer below image.

    When SBL binaries are used, you first keep the EVM in UART boot mode and send the SBL binaries to the EVM's flash memory using UART protocol.

    Once the flashing is complete, boot mode is switched to OSPI which tells the SOC to read image from OSPI flash when the SoC is reset or power cycle is done. The OSPI flash on EVM is non-volatile and does not lose its content when power cycle is done.

    Once the SoC is initialized either by SBL or CCS+GEL flow, you can follow the steps mentioned at CCS_LAUNCH to debug the application through CCS.

    Please refer below image.

    Hope the above information clarifies the confusion. 

    Regards,

    Tushar

  • Hello Mr. Tushar, 

    Following your previous reply, Is this correct?

    if I use DEV-BOOT mode, the "gmake -s -C examples/..... " needs to be executed everytime I power-on/off the AM243x-LP demo-board to do SoC initialization. 

    Please comment. 

    Thank you very much. 

    Best Regards,   JasonChiu. 

  • Hello Mr. Jason,

    gmake -s -C examples/.....

    You don't need to run the gmake command again and again. As you already have created binary once in you system using above command.

    All you need is to reload and re-run the same binary again on R5F0-0 core after a reset or power cycle. The binary can be reloaded and re-run either via directly loading as suggested in video provided earlier or via running the load_dmsc_hsfs.js script.

    Regards,

    Tushar

  • Hello Mr. Tushar, 

    Thank you very much for your detailed explanations. 

    I successfully dubug two cores using single-step on two examples wihtout problem now. 

    You are great on helping novice learners who is not familiar with TI chip/CCS. 

    Best Regards,   JasonChiu.