AM6422: How to generate an interrupt from RTU to R5 with FreeRTOS

Hi,

xixiguohx said:

So we can not use the syscfg as MCU SDK R5 examples

Can you help me understand what you mean by this? It would be good to use Sysconfig for INTC mapping, see AM64x Sysconfig for INTC

Aside from that, the steps to generate interrupt from PRU to R5F is mentioned in the E2E you've attached above, same should be followed for RTU as well. Please try that and let me know if you face any issues.

Regards,

Nitika

Hi Nitika，

Thanks, I will trying to do it and update the result here.

But there's an other question. We used the PRU GPI0-7, it means that we will read register R31.b0(bits 7-0) periodically. If we also periodically written the R31(bits 3-0) to generate interrupt event from PRU to R5, will it influence the read value of R31.b0?

Nitika Verma said:

Can you help me understand what you mean by this? It would be good to use Sysconfig for INTC mapping, see AM64x Sysconfig for INTC

Because we already have legacy PRU projects created followed https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/ examples. I don't know how to combine the legacy PRU projects with R5 FreeRTOS projects in both CCS develop environment and Linux yocto develop environment. So I want to add the generating of PRU interrupt to R5 FreeRTOS directly in PRU legacy projecs.

Best Regards

xixiguo

Hi,

xixiguohx said:

Because we already have legacy PRU projects created

Understood, there are 2 ways you can go ahead here (for CCS environment and FreeRTOS):

1. First would be to add all the required configurations (mentioned in TRM section 6.4.7.2) in the PRU project itself.

2. MCU+ SDK AM64x has an EXAMPLES_PRU_EMPTY example which is a combination of a PRU project and a R5F project. All the PRU code remains in the PRU project, on building the PRU project firmware header files are generated which get included in the R5F project include options by default. R5F project is built using the the sysconfig files and loads the PRU project binaries onto the PRU core.
You can move your PRU code to the PRU project here and use sysconfig for some of the required configurations.

xixiguohx said:

If we also periodically written the R31(bits 3-0) to generate interrupt event from PRU to R5, will it influence the read value of R31.b0?

You will have to make sure that your operations are atomic. An interrupt will only be generated when RTU core writes to R31 register. That value will then be overwritten by the input being received on R31.

How does your design look like? Are you reading from R31 and then generating an interrupt or the opposite?

You mentioned Linux development environment as well, if you have any Linux specific questions I would recommend you to create a new thread so it gets assigned to our Linux PRU expert.

Regards,

Nitika

Hi Nitika，

Thanks for your reply.

Nitika Verma said:

How does your design look like? Are you reading from R31 and then generating an interrupt or the opposite?

My design will have the case that after written the R31 to generate an interrupt event to R5, and before R5 to deal it, we have to read the GPI from R31.

And how to understand here,

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/783813/compiler-am6548-can-t-write-to-r31-of-pru#:~:text=Certainly%20you%20can,were%20you%20expecting%3F

Does it mean that the writing interrupt event to R31 will not influence the reading of R31 GPI? And the writing interrupt event to R31 also will not be influenced by the input GPI from R31? Writing interrupt event to R31 and reading input from R31 GPI do not affect each other?

Best Regards

xixiguo

Hi,

xixiguohx said:

And how to understand here,

In this E2E, it mentions that the value you write to R31 in order to generate interrupts will not be reflected in the value read by the application and the CCS debugger. The reason for this is, once you write to R31, a system event gets triggered and after that its value reverts back to the old state (this happens in the same PRU cycle, no additional delay). 

I tested this on my end,
If input signal is not mapped, after you write to R31 it gets changed to 0.
If input signal is enabled, then it gets changed to the input status.

Regards,

Nitika

Hi Nitika,

Nitika Verma said:

If input signal is not mapped, after you write to R31 it gets changed to 0.
If input signal is enabled, then it gets changed to the input status.

Thank you for the test, it helps me understand the R31.

Based on your test, I think in my case it should works. I will update the result here later.

The E2e here,

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1225348/am6442-generating-an-interrupt-from-pru-to-r5f/4635548?tisearch=e2e-sitesearch&keymatch=pr0_pru_mst_intr%25255B15%25255D_intr_req#4635548:~:text=I%20gutted%C2%A0%20/examples/motor_control/benchmark_demo/am64x%2Devm/r5fss0%2D0_nortos/main.c%20to%20create%20this%3A

is for R5 nortos. Is there any example like this for R5 FreeRTOS?

My R5 FreeRTOS code refer to e2e above is like below,

#include <stdlib.h>
#include <kernel/dpl/DebugP.h>
#include "ti_drivers_config.h"
#include "ti_board_config.h"
#include "ti_drivers_open_close.h"
#include "FreeRTOS.h"

#include <drivers/pruicss.h>
//#include <pru_ipc.h>

volatile uint32_t intEvent      = 0UL;
volatile uint32_t intCapt       = 0;
volatile uint32_t intNum        = 0UL;
HwiP_Params       hwiPrms;
HwiP_Object       HwiObject;

static void IsrFxn(void *args)
{
    intNum = (uint32_t)args;

    intEvent++;
    intCapt++;
    HwiP_clearInt(intNum);
}

int pru_int(void)
{
    
    uint32_t    intNum = 255;
    int32_t     retVal;

    DebugP_log("\r\nSTART INTC test App\r\n");
    HwiP_Params_init(&hwiPrms);

    DebugP_log("HWI START\n");

    hwiPrms.intNum   = intNum;
    hwiPrms.callback = IsrFxn;
    hwiPrms.args     = NULL;

    HwiP_init();
    DebugP_log("HWI init pass\n");
    retVal           = HwiP_construct(&HwiObject, &hwiPrms);
    DebugP_assert(retVal == SystemP_SUCCESS);
    DebugP_log("Interrupt 255 initialized\n");

    HwiP_enable();
    DebugP_log("HWI Enabled\n");

    /*while(1)
    {
        if(intCapt != 0)
        {
            intCapt = 0;
            DebugP_log("interrupt 255 received %d times\n", intEvent);
        }
    }*/

    return 0;
}

But it will blocked in HwiP_init(), and never return. 

Best Regards

xixiguo

Hi,

Apologies for the delayed response, I did not receive a notification about your reply edit. 

If you are looking for a freeRTOS based sample code, I would suggest you to use the AM64x empty project at '<mcu_plus_sdk>\examples\empty\am64x-evm\r5fss0-0_freertos' and add your changes on top of that.

This example will have all the libraries required for a freeRTOS project included in it by default.

Regards,

Nitika

Hi Nitika,

I tried the empty project and add my changes, it's the same result that block at HwiP_init(). Can you give me your email and I will send my R5 project to you?

Best regards

xixiguo

Hi,

I have received your project files. Allow me some time to look into it and get back to you.

Regards,

Nitika 

Hi Nitika,

Is there any updates about this topic? Does my files have any mistakes?

Best Regards

xixiguo

Hi,

Thank you for the ping.

Yes, in your code you are calling HWIP_init in empty.c, that call is not needed since the System_init() call in main.c already calls HWIP_init.

You can remove the call from empty.c and continue your implementation.

It will be better to refer to any existing freeRTOS project for your use case to make sure you are making all the required function calls.

Please ping the thread if you face any other issues.  

Regards,

Nitika

Hi Nitika,

Sorry for the late reply, because we have our National Day holiday last week. 

The R5 project can run after remove the function HWIP_init. But R5 can not receive the interrupt from ICSSG1_PRU0. I'm not sure if the mapping I defined in both R5 and PRU0 are correct. Could you help to check it?

BR

xixiguohx

Hi,

As discussed, there might still be couple of changes needed in your interrupt configuration code. Lets continue our debug with your code over email.

I will try to test the implementation on my setup by early next week.

Regards,

Nitika