PRUSS interrupt mapping for IRQ > 60 on AM3359

Chris,

Please refer to Table 6-3 in ARM335x Technical Reference Manual (TRM). There is no mention of Timer 3 mapping to PRU subsystem.

If you need a timer, you can try using the eCAP module (Section 4.8 and Section 15.3 of TRM).

Thanks.

>If you need a timer, you can try using the eCAP module (Section 4.8 and Section 15.3 of TRM).

Oh okay, I didn't look very closely at that.  I didn't realize it could be used to generate a clock.

It seems to me that a lot of PRU applications are going to need some kind of clock, especially if you think back to the PRU's roots as a custom communication controller.

Thanks for the response,

--Chris

The eCAP runs at 200MHz unless software tries to run at another frequency. Maximum rated frequency is 200MHz. In 10 seconds, it counts to 2 billion. We tested and it works as expected.

One other option is to use the IEP timer. The registers are available at base address 0x4A30_0000 where PRUSS range starts. And the following fields can be used:

Offset 0x0002_E000 bit[0] enable bit to enable/disable counter (1=enable, 0=disable)

Offset 0x0002_E004 bit[0] indicates if counter had an overflow (write 1 to this bit to clear overflow status)

Offset 0x0002_E00C bit[31:0] has the 32-bit counter at 200MHz (can be overwritten any time)

This timer also runs at 200MHz by default.

Thanks!

Thanks.  I think we have the eCAP working.

Suppose we wanted to use an external timer, and poll its interrupt flag over L3/L4.  How terrible would that be?  Is it possible that the PRU polling an external timer (e.g. DM Timer 3) overflow flag directly over L3/L4 in a tight loop could stall the MPU or cause it to slow down because it's competing for the interconnect?

I ask this because 'events' in the PRU involve polling, too; just more efficiently because what's being polled is in R30/R31.

-C

It is okay to poll external timers. It will be few tens of cycles of latency per such poll. But I would prefer using internal timer over external timer.

The interconnect is switched - there is no sharing of interconnect resources if the source and target for a transaction do not overlap with source and target of another concurrent transaction. There could be congestion if, for example, a bridge is present on the way to L4 for transactions from two different initiators on L3 accessing addresses beyond L4 at the same time. Determinism can usually not be guaranteed for transactions on L3/L4 in a busy system.

Regards,

Maneesh

Ahh okay.  This leads me to two questions.

First, there are four ports out of L4_PER.  The MPUSS (main cpu) has port 0 all to itself, and the PRUSS has port 1 exclusively.  Do these ports operate completely independently?  Example: could the PRUSS access DMTIMER3 (PORT 1) and at the exact same time the MPU access DCAN0 (PORT 0) without contention or congestion?

Second, the drawing of 3 (Figure 10-1 in AM335x TRM Rev C) shows L3F and L3S with some kind of barrier between them.  The text indicates that they are on two separate clock domains.  Suppose the PRUSS initiator on L3F wants to talk to a target on L3S.  Is the transition from the fast clock domain L4 to the slow L3 clock domain  another congestion point?

If there is no other activity besides these two transactions, then yes, the access from ARM to DCAN and the access from PRUSS to DMTIMER3 will get processed concurrently.

There are multiple paths from fast to slow clock domain as well. That will ensure you can have these two transactions going on in parallel.

Thanks.