• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 4226 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PRUSS Resource Table Guide?

Nicolas Dammin
Prodigy 120 points
Other Parts Discussed in Thread: AM3359

Hello,

I want to program a 8-bit parallel interface with PRU1 on the AM3359 using the GPI pins. I have set up the remap and when I debug the PRU core with CCS6, I get the data in the R31 Register.

Now I want to send an interrupt to the ARM running Linux every time I get a new 8-Bit data input (triggered by a 9th input pin, which acts as a clock input). But I don't understand how the R31 register exactly works. It has three modes: Event out Mapping, Status Mapping and General Purpose Inputs. Is it even possible to use the GPIs AND the Interrupt Control? How does this work?

I also found out that I have to set up some interrupt mappings in the resource table. Is there any manual or guide available for the resource table file? Like a list of commands, what all those commands like 

#pragma DATA_SECTION(am335x_pru_remoteproc_ResourceTable, ".resource_table")
#pragma RETAIN(am335x_pru_remoteproc_ResourceTable)

exactly do? I would like to know how this resource table for remoteproc works.

Best regards

Nicolas Dammin

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will ask the PRU experts to comment.
  • 0 in reply to Biser Gatchev-XID
    TI__Genius 10440 points

    Nicolas,

    Which version of the Processor SDK are you using? Please include the version number as well as RTOS or Linux.

    Jason Reeder

  • 0 in reply to Jason Reeder
    Prodigy 120 points

    Hello Jason,

    I'm working with the Processor SDK 02.00.01.07 with Linux and PRU Package 04.00.01.00 I think.

  • 0 in reply to Nicolas Dammin
    TI__Genius 10440 points

    Nicolas,

    When you read register R31, the value in bit 31 corresponds to the Host-0 interrupt, the value in bit 30 corresponds to the Host-1 interrupt, and the values in bits 29:0 are the general purpose input values that come from the external pins. This is shown in section 4.4.1.2 of the AM335x TRM. 

    When you write register R31, you have the ability to generate 1 of 16 events that correspond to events in the PRU-ICSS interrupt controller block. The event that you generate depends on the the value in bits 3:0 when you strobe bit 5. This is shown graphically and described in section 4.4.1.2.2 of the AM335x TRM. 

    Table 4-21 in section 4.4.2.2 of the AM335x TRM shows the 64 events that come into the interrupt controller of the PRU-ICSS. Int Numbers 16 through 31 in that events table shows the 16 events that you can generate by writing to register R31.

    The PRU-ICSS INTC Overview in section 4.4.2.1 along with figure 4-17 in the same section discusses how the 64 events get mapped into 10 channels and then those 10 channels get mapped to 10 host interrupts.

    This last piece, the event to channel to host interrupt mapping of the PRU-ICSS INTC block can be described in the resource_table and then configured by Linux as your PRU firmware is loaded for you. There are examples on how to do this in the PRU Software Support Package that is installed in your Processor SDK.

    Check out:

    pru-icss-4.0.1/examples/am335x/PRU_RPMsg_Echo_Interrupt0/resource_table_0.h (event 60 - channel 0 - host 0)

    pru-icss-4.0.1/examples/am335x/PRU_RPMsg_Echo_Interrupt1/resource_table_1.h (event 59 - channel 1 - host 1)

    pru-icss-4.0.1/examples/am335x/PRU_Direct_Connect0/rsc_table_pru0.h (multiple configured)

    for examples on how to map the events to the channels and the channels to the host interrupts.

    The AM335x TRM can be found here: 

    Jason Reeder

  • 0 in reply to Jason Reeder
    Prodigy 120 points

    Hello Jason,

    thank you very much for that detailed answer! I think I do now understand how the Interrupt Controller of the PRUs works. But I'm still a bit confused about the programming. In the PRU_to_ARM example, the resource table is empty and the INTC is configured inside the pru firmare source code itself. In the RPMSG examples, the INTC is configured in the resource table file and not the firmware source.

    How do I react to an HOSTEVT interrupt on the Linux side? There are no example programs for Linux in the PRU folder of my SDK.

    AFAIK, if I map the pr1_pru_mst_intr[0]_intr_req, which is event No. 16, to Channel 2 and map Channel 2 to Host 2, and I write 0x20 to the __R31 register, it should fire an HOSTEVT0 interrupt on the ARM processor, right?

    I try to poll the HOSTEVT0 like in the poll.c userspace example of PRU-framework-master, but nothing happens. Did I get it completely wrong? I just want to fire a simple interrupt on PRU1 that will inform Linux that something happened by writing something into the R31 register. 

    Regards

    Nicolas Dammin

  • 0 in reply to Nicolas Dammin
    TI__Genius 10440 points

    Nicolas,

    The resource table is the recommended method to program the PRU-ICSS INTC if you are running Linux on the ARM core. You describe the event to interrupt mapping that you would like in the resource table and then the Linux driver configures the INTC for you before booting the PRU cores.

    However, it is also possible create the exact same mapping by writing PRU code to configure the registers of the INTC. This is shown in the PRU_to_ARM example that you mention. This method would be used by customers that are not running Linux on the ARM core (bare-metal or RTOS).

    The Host 2 interrupt in the PRU INTC will trigger interrupt 20 on the ARM core which is called PRU_ICSS_EVTOUT0 in Table 6-1 of section 6.3 of the AM335x TRM.

    You will need to talk to the author of the PRU-framework to determine why your poll.c userspace program is not working. It appears like the author modified the pruss_remoteproc driver to add sysfs entries that the poll.c program tries to use.

    The TI supported method to send a message from the PRU to the ARM would be to use RPMsg which is provided in the PRU Software Support Package: 

    Jason Reeder

  • 0 in reply to Jason Reeder
    Prodigy 120 points
    Hello Jason,

    Thank you for your quick answer.

    The problem with RPMsg is, that it needs too much CPU cycles of the PRU to work. I want to have a very fast data transfer (20-40 Mbyte/s) from a parallel 8-Bit input using the PRUs GPIs to the ARM Core running Linux. To make this possible, I thought about writing each received byte on the PRU shared RAM using PRU Assembler, sending an Interrupt to the ARM Core and read out the RAM by Linux, all within 5-10 PRU CPU cycles per Byte. I don't know if that is even possible, but I wanna try to get the fastest data transfer possible.
    I will try to get in contact with the person who wrote the PRU-Framework if he has an idea how to solve my problem.

    Regards
    Nicolas Dammin