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.

LP-AM243: Trying to create multicore (system) app with R5F and PRU0...

Part Number: LP-AM243
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

This is a follow-up post to this question.

I created a new workspace, and imported the system_freertos example.
I updated the empty_am243x-lp_system_freertos "system.xml" file to include a PRU core.

Next I copied over my R5F program, and my PRU (assembly) program.
After setting up the right header file links and copying linker.cmd for PRU,
I was able to connect to the LP target, and load the programs in their cores and run.

I load the PRU program and run it, then load the R5F program and run it.
(The R5F program writes to DMEM0 which PRU can see to tell PRU when to do actions)

However, when I try and flash the binary to OSPI the PRU doesn't seem to be running at all.
Am I missing something to enable the PRU core?

In CCS I just click the green "RUN" arrow to run the program, but with multicore do I need to engage the PRU through some register write?
Is there a multicore example with PRU running I can reference...?

  • Hi Keito,

    Thanks for reaching out to Texas Instruments E2E support forum.

    I have taken your inputs and working on it. Please allow some time to revert back.

    Regards,

    Tushar

  • Hi Keito,

    Currently we do not have an example with PRU as part of a mutlicore project. Is there a specific requirement for which you are looking at creating the system project?

    Another way to work with a combination of PRU and R5F project is to use the empty pru_io example present in MCU+ SDK - EXAMPLES_PRU_EMPTY

    Here you can just flash the R5F application and that will load the PRU firmware onto the core and start the core execution.

    You can look at the above method as well if it meets your requirements. Do let me know if you still want to continue with a system project approach.

    Regards,

    Nitika

  • Nitika,

    Thanks; I figured it out.

    Using MCUSDK v902 I just imported the two projects (the empty pru0 project and the r5f freertos project).
    I create the PRU application and build, which generates a *.h file with binary data for PRU.
    A link is automatically generated so the freertos program #include <...> can open this binary data.
    The freertos program then just loads it into PRU memory and we are good to go.

    For some reason DebugP_log(""); isn't printing anything...Can't do keyboard input either...
    any thoughts on why?

  • Can you share your R5F project so I can have a look at it? Or if that is not possible, can you explain what you are trying to do in your example?

    Regards,

    Nitika

  • Hi Nitika,

    I was using MCUSDK901 until now.
    In SYSCFG if you disable "print to CCS" log, the API calls for DebugP_log("..."); will actually print log info to the COM port.
    I was using this.

    But now using MCUSDK902, I noticed that if prints to CCS are disabled, nothing is printed out to COM port anymore.
    (If prints to CCS is enabled, I can see the DebugP_log() prints fine)

    DebugP_log API just made interacting with the COM port really easy...
    I guess I need to go learn how to use the UART API...

  • Hi Keito,

    For terminal logs, you should have the "Enable UART Log" selected in the sysconfig. Do you have this setting enabled?

    Regards,

    Nitika

  • Hi Nitika, 

    I figured it out. (Yes, Enable UART Log was selected).

    The issue was, the example project comes with a *.c file which does the loading of firmware to PRU core.
    This code calls the Drivers_open() which is needed for UART w/ DebugP_xxx API calls.

    But I copied over my R5F project *.c file, which included another Drivers_open() and Board_driversOpen() calls.
    (After firmware is loaded to PRU call, that function calls my main project function)

    By removing the Drivers_open() and Board_driversOpen() calls in my R5F *.c file, everything works fine.

    I guess calling Drivers_open() twice isn't good?