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: PRU debug issues in CCS

Part Number: MCU-PLUS-SDK-AM243X


Hi,

I am trying to debug ICSSG0_PRU0 and I am having limited success.  If I debug in the SPI boot mode, I can get GPO0 to output, but only if I debug the R5 core, then debug the PRU, and I only seem to be able to toggle GPO0 via R30 regardless of my syscfg settings.  I then tried to put the system into no boot mode and load the dmsc.js file through the console.  That allows me to get into debug but it seems not to run the main.c file I have associated with the core in the system.xml file.  Am I missing a gel file to load the core in debug or something.  Also is there a way to debug the ARM cores and the other cores at the same time?  The end goal here is to send data back and forth between the cores using the PRU to send data back and forth to some peripherals. 

Thanks!

  • Hi

    If I debug in the SPI boot mode, I can get GPO0 to output, but only if I debug the R5 core, then debug the PRU, and I only seem to be able to toggle GPO0 via R30 regardless of my syscfg settings.

    Are you using the bootloader from SDK itself?
    Did you configure the pinmux for GPO for all 20 pins in this case?

    That allows me to get into debug but it seems not to run the main.c file I have associated with the core in the system.xml file.  Am I missing a gel file to load the core in debug or something.  Also is there a way to debug the ARM cores and the other cores at the same time?

    I was not able to fully understand this. Can you give more details? Which system.xml file is this, and which SDK example are you running here?

    Regards
    Dhaval

  • Hi Dhaval,

    I am using the boot loader settings as set with the dip switches on the launchpad.  I have tried No Boot and QSPI. 

    For the pin muxing I am setting to GPO in the syscfg.  Example:

    When I run a standard debug with the ARM core I get:

    And I am able to get an output on GPO1 but only that pin. 

    For debugging the PRU I am running:  loadJSFile "C:/ti/mcu_plus_sdk_am243x_08_06_00_45/tools/ccs_load/am243x/load_dmsc.js"

    And I get:

    When I connect to PRU0 I get "Connecting: In Reset"

    The system.xml looks like this:

    The basic PRU code I am using to test things out is:

    Hopefully this helps to clarify things a bit.  If not please let me know and I will offer more info.

    Thanks!

  • Hi

    Sorry for the delayed response.

    The issue here is that when you run load_dmsc.js or SBL NULL, clocks for PRU-ICSSG are not initialized. That is why you are unable to connect to the cores directly.

    Can you check if the steps from following E2E help you?

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1045297/faq-am64x-am24x-how-to-use-code-composer-studio-ccs-to-connect-to-pru_icssg

    Regards
    Dhaval Khandla

  • Hi Dhaval,

    I have read through that procedure before but will give it a shot again.   Before I do however, can you clarify something for me?  What is happening in the "Flash the SOC Initialization binary" step?  Is this different than flashing a hello world program through CCS?  The instructions seem to imply this is overwritten by other apps, so I am trying to understand why this step is performed.  Is this just to verify that things are working as expected?  Or is this to make sure the following is set correctly:  "For SDK 8.1 and earlier, the OPSI SBL NULL initialization binary does not enable PRU clocks."?

    Thanks!

  • Hi

    Before I do however, can you clarify something for me?  What is happening in the "Flash the SOC Initialization binary" step?

    In this step, SBL NULL is flashed onto the device. More details on bootloaders are provided in documentation here : https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/09_00_00_35/exports/docs/api_guide_am243x/BOOTFLOW_GUIDE.html

    With SBL NULL, the user application still needs to be loaded through CCS. SBL NULL does required SoC initialization and keeps the application cores in reset state, which can be loaded an run from CCS. Unfortunately the current SBL NULL does not initialize PRU-ICSSG clocks, because of which connection to PRU fails.

    Regards
    Dhaval Khandla