AM4376: Missing Rx interrupts in EtherNET/IP

Stefan,

I'm sorry, the best resource to help answer this is out for the rest of this week. We will reply early next week. I'm sorry for the delay.

Hello,

thanks for the intermediate update.

In the meantime I did some investigations to find out why the Rx interrupts are missing - unfortunately without success.

Best regards

Stefan 

Hello,

while trying to identify the reasong for the missing interrupts I had a closer look at ICSSSwitchConfig in iscc_emacFwInit.c. I tried to understand the buffer and queue setup but could not find any documentation for the descriptor composition. 

So I tried to understand the descriptor setup from what is written into the data RAM.  For example, the tx context setup for port 1 contains the following descriptor for queue 1:

I assume this means, that tx buffers for queue 1 of port 1 start at offset 0x6100 and ends at offset 0x6D00 in (L3 OCMC RAM). Further, the tx buffers for queue 1 of port 1 start at offset 0x10020 and end at offset 0x11A0. This seems to be identical for all tx queues of port 1 and 2.

When looing at the rx buffers of the host port 3, the rx context setup seems to follow a different mapping. Example for rx context of host port and queue 1:

Here, the offset of the last buffer (0x1E7C) seems to be wrong. The host queue has 194 buffers with each 32 bytes. So I would expect that the last buffer should be at 0x1820.

Ist this correct or are the rx buffer descriptors set up in a different way?

Best regards

Stefan

Stefan,

For Rx interrupt issue, have you checked the RXCFG and RXERR registers of ICSS MII RT? Also, make sure the pinmux is configured properly.

For rx buffers descriptors setup, you may step into the ICSSSwitchConfig() to deduce how 0x1E7C0000 is set.

Regards,

Garrett

Hello Garrett,

thank you for your reply.

MII_RT registers

I have checked the MII_RT register an could not find any pending receive errors. The configuration looks OK to me:

MII_RT.RXCFG0 = 0x00000015 (MUX = port 0, RX enabled, preamble cut off)
MII_RT.RXCFG1 = 0x0000001D (MUX = port 1, RX enabled, preamble cut off)
MII_RT.RXERR0/1 = 0 (no errors)

The MII_RT configuration registers are set by the ICSS_EMAC. I attatched a screenshot of the complete MII_RT register set.

PINMUX

I have checked the pinmux configuration for ICSS0/1 against the one found in pdk_am437x_1_0_13/.../straterware/board/am43xx/am43xx_idkevm_pinmux_data.c.

On our hardware platform we connected the following signals:

• pr1_miix_txd[0..3]
• pr1_miix_rxd[0..3]
• pr1_mii_mtx_clk
• pr1_mii_mrx_clk
• pr1_miix_tx_en
• pr1_miix_rx_dv
• pr1_miix_rx_er
• pr1_miix_crs
• pr1_miix_col
• pr1_mdio_mdclk
• pr1_miix_data

Signals pr1_miix_rxlink are not connected, LINKSEL in MDIO_USERPHYSELX is set to 0 (link state determined by MDIO state machine). Signal pr1_mdio_mdclk is connected to pin C24 with MMODE = 8 (instead of A12 with MMODE = 5 on IDK board). The remaining differences are located in pullup/down selection. I adapted the pull up/down settings to our platform but I still don't get any receive interrupts.

As stated in the "PRU-ICSS EtherNet/IP adapter Firmware Data Sheet" (from 06.2017) these pins are optional. Can you plese confirm that signals pr1_miix_rxlink are not required by the EhterNet/IP adapter firmware?
Are there any other ICSS0/1 related signals (not listed before) that are needed by the EhterNet/IP adapter firmware?

PRU FIRMWARE

In the ethernetip_adapter example, the EhterNet/IP adapter firmware v1.0 is used for CPU AM437x:

#if defined(SOC_AM335x) || defined(SOC_AM437x) || defined(SOC_AMIC110)
#include <protocols/ethernetip_adapter/firmware/v1.0/ethernetip_adapter_pru0_bin.h>
#include <protocols/ethernetip_adapter/firmware/v1.0/ethernetip_adapter_pru1_bin.h>
#else
(...)

In the online documentation I found the information that AM437x firmware v2.1 shall be used. Unfortunately, I was not able to find the corresponding document where I have seen the information. Which version is the right one for AM437x?
I tried both versions (v1.0 and v2.1) but I don't get any receive interrupts.

ICSS-EMAC configuration

Another weird poit ist the priority queue selection in the ICSS_EMAC configuration. In the ethernetip_adapter example, priority queue is set to ICSS_EMAC_QUEUE3 (queue index = 2). In the ICSS_EIP_Adapter_Developer_Guide it looks like queue index 3 (ICSS_EMAC_QUEUE4) is dedicated to TCP/IP communication. I guess, the queue selection has nothing to do with the muissing receive interrupts. Which queue has to be selected as priority queue for the ICSS_EMAC?

FURTHER OVSERVATIONS

• After the PRU0/1 registers are configured by ICSS_EmacInit the PRU0/1 firmware (v1.0 or v2.1) is loaded and enabled. Host interrrupts are enabled and cleared, too. The PRU0/1 fimrmware is running (RUNSTATE = 1, PCTRR = counting). I attatched a screenshot of the complete PRU0/1_CTRL register set.
• The interrupt PRU => Host mapping (INTC) looks OK to me. Link interrupts are successfully genereated for link up/down events on both ports, all host interrupts are enabled (PRU_ICSS_INTC_HIER = 0x3FF), all system events (20..26, 41, 42, 53, 54) are enabled (PRU_ICSS_INTC_ESR0/1).
• I can see pending receive events PRU_ICSS_INTC_HIPIR0 (event 42) and PRU_ICSS_INTC_HIPIR1 (event 54). Having a look at the L3 OCMC RAM I can also see receive frames that have been copied from the Ethernet bus to the Rx Context buffers at offset 0x48C0 (Queue 4). So it seems to me that the firmware has received frames, copied them to L3 but does not issue system event 20 (PRU_ICSS_INTC_HIPIR2 = 0x80000000).

Best regards

Stefan

Hi Stefan,

It was U.S holiday. I was just able to look into your input. Some quick update:

pr1_miix_rxlink is used for fast link detection in the protocol such as EtherCAT. It's not used in Ethernet/IP. The signals you listed for MII RT appear to be sufficient.

Firmware v1.0 is the correct one for AM437x.

I will review your detailed description and respond asap...

Regards,
Garrett

Hi Stefan,

>>So it seems to me that the firmware has received frames, copied them to L3 but does not issue system event 20 (PRU_ICSS_INTC_HIPIR2 = 0x80000000).

Have you also tried to dump and compare the INTC registers with default TI RTOS application which might give some clue? The system event 20 really should happen if the frames have been copied to L3 as there is no any mod on PRU firmware while you port the host application from TI RTOS to Nucleus RTOS.

Is it possible to run the loopback unit test (ICSS_EMAC_BasicExample_idkAM437x_wSoCFile_armtestproject) of icss_emac driver from PDK on your board? 

Regards,

Garrett

Hello Garrett,

>> Have you also tried to dump and compare the INTC registers with default TI RTOS application which might give some clue?

No, I haven't done that, yet. Our idk437x hardware is currently not available. I just took the INTC configuration from "examples/ethernetip_arapter/tiswitch_pruss_intc_mapping.h" and let the ICSS_EMAC do the configuration. As far as I have seen, all examples do it in the same way.

I have checked the INTC configuration multiple times and could not find any issue. I get link interrupts for both ports and I can manually issue event 20 by writing 0x00100000 into PRU_ICSS_NTC_SRSR0 and the host interrupt is gegerated sucessfully. Therefore, I assume that the INTC confogiration must be correct for link and RX interrupts.

• What about the register mapping I have provided (screenshots)? Could you see any problematic settings?
• In the PRU_ICSS_INTC_HOHIR0/1 register, events 42 and 54 keep on pending after they appeared the first time. I would expect, that the PRU will clear them after issuing event 20. Is this correct? May this be a hint?

>> Is it possible to run the loopback unit test (ICSS_EMAC_BasicExample_idkAM437x_wSoCFile_armtestproject) of icss_emac driver from PDK on your board?

I tried to do adapt the example to our platform but get stuck because ...

• The PRU firmware is available as binary image. I am not sure, if I can directly copy the binary data to the PRU's instruction memory. If i do so, the PRUs seem not to work properly (instruction stall, etc.).
• The test wants to preload the data ram of the PRUs, but I was not able to locate the related content behind pru_dmem0_rev1_start ... pru_dmem0_rev1_end and pru_dmem1_rev1_start ... pru_dmem1_rev1_end.

When I continue running the test, the resulting situation is nearly the same. I get link interrupts, but the PRU does not seem to do anything than incrementing the program counter.

• How do I load the instruction memories using the firmware binry files? Just ba passing the binary content to PRUICSS_pruWriteMemory?
• Where can I find the data ram content that is located behind pru_dmem0_rev1_start and pru_dmem1_rev1_start?

Best regards

Stefan

Stefan,

Except the SRSR0, SECR0 and HIPIR2, other register mappings looks OK. Please find the attached register dump when ICSS_EmacRxInterruptHandler is hit: 

521177 32
R PRU_ICSS1_INTC_PRU_ICSS_INTC_REVID 0x0000000B 0x4E82A900
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_GER 0x0000000B 0x00000001
R PRU_ICSS1_INTC_PRU_ICSS_INTC_GNLR 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SISR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SICR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_EISR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_EICR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIEISR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIDISR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_GPIR 0x0000000B 0x0000002A
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SRSR0 0x0000000B 0x00104180
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SRSR1 0x0000000B 0x0000040C
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SECR0 0x0000000B 0x00100000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SECR1 0x0000000B 0x00000400
R PRU_ICSS1_INTC_PRU_ICSS_INTC_ESR0 0x0000000B 0x07F00000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_ESR1 0x0000000B 0x00600600
R PRU_ICSS1_INTC_PRU_ICSS_INTC_ECR0 0x0000000B 0x07F00000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_ECR1 0x0000000B 0x00600600
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR0 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR1 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR2 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR3 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR4 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR5 0x0000000B 0x05040302
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR6 0x0000000B 0x00080605
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR7 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR8 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR9 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR10 0x0000000B 0x00000700
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR11 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR12 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR13 0x0000000B 0x00010700
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR14 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR15 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HMR0 0x0000000B 0x03020100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HMR1 0x0000000B 0x08060504
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HMR2 0x0000000B 0x00000009
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR0 0x0000000B 0x0000002A
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR1 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR2 0x0000000B 0x00000014
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR3 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR4 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR5 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR6 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR7 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR8 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR9 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SIPR0 0x0000000B 0xFFFFFFFF
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SIPR1 0x0000000B 0xFFFFFFFF
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SITR0 0x0000000B 0xF80FFFFF
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SITR1 0x0000000B 0xFF9FF9FF
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR0 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR1 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR2 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTCINTC_HINLR3 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR4 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR5 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR6 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR7 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR8 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR9 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIER 0x0000000B 0x000003FF
R PRU_ICSS1_PRU1_CTRL_PRU_ICSS_CTRL 0x0000000B 0x00000001
R PRU_ICSS1_PRU1_CTRL_PRU_ICSS_CTRL_STS 0x0000000B 0x00000038
R PRU_ICSS1_PRU1_CTRL_PRU_ICSS_CTRL_WAKEUP_EN 0x0000000B 0x00000000
R PRU_ICSS1_PRU1_CTRL_PRU_ICSS_CTRL_CYCLE 0x0000000B 0x00000000
R PRU_ICSS1_PRU1_CTRL_PRU_ICSS_CTRL_STALL 0x0000000B 0x00000000
R PRU_ICSS1_PRU1_CTRL_PRU_ICSS_CTRL_CTBIR0 0x0000000B 0x00000000
R PRU_ICSS1_PRU1_CTRL_PRU_ICSS_CTRL_CTBIR1 0x0000000B 0x00000000
R PRU_ICSS1_PRU1_CTRL_PRU_ICSS_CTRL_CTPPR0 0x0000000B 0x00000100
R PRU_ICSS1_PRU1_CTRL_PRU_ICSS_CTRL_CTPPR1 0x0000000B 0x00003000
R PRU_ICSS_MII_RT_RXCFG0 0x0000000B 0x00000015
R PRU_ICSS_MII_RT_RXCFG1 0x0000000B 0x0000001D
R PRU_ICSS_MII_RT_TXCFG0 0x0000000B 0x00400103
R PRU_ICSS_MII_RT_TXCFG1 0x0000000B 0x00400003
R PRU_ICSS_MII_RT_TXCRC0 0x0000000B 0xA301FA13
R PRU_ICSS_MII_RT_TXCRC1 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_TXIPG0 0x0000000B 0x000000B8
R PRU_ICSS_MII_RT_TXIPG1 0x0000000B 0x000000B8
R PRU_ICSS_MII_RT_PRS0 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_PRS1 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_RXFRMS0 0x0000000B 0x05F1003F
R PRU_ICSS_MII_RT_RXFRMS1 0x0000000B 0x05F1003F
R PRU_ICSS_MII_RT_RXPCNT0 0x0000000B 0x000000E1
R PRU_ICSS_MII_RT_RXPCNT1 0x0000000B 0x000000E1
R PRU_ICSS_MII_RT_RXERR0 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_RXERR1 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_RXFLV0 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_RXFLV1 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_TXFLV0 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_TXFLV1 0x0000000B 0x00000000

For the event status clear, see the description of SECR0 Register:

The System Event Status Enabled/Clear Register0 show the pending enabled status of the system events
0 to 31. Software can write to the Status Clear Registers to clear a system event after it has been
serviced. If a system event status is not cleared then another host interrupt may not be triggered or
another host interrupt may be triggered incorrectly.

The register dump aligns with the description when the ISR doesn't happen:

521177 32
R PRU_ICSS1_INTC_PRU_ICSS_INTC_REVID 0x0000000B 0x4E82A900
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_GER 0x0000000B 0x00000001
R PRU_ICSS1_INTC_PRU_ICSS_INTC_GNLR 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SISR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SICR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_EISR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_EICR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIEISR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIDISR 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_GPIR 0x0000000B 0x0000002A
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SRSR0 0x0000000B 0x00004180
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SRSR1 0x0000000B 0x0000040C
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SECR0 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SECR1 0x0000000B 0x00000400
R PRU_ICSS1_INTC_PRU_ICSS_INTC_ESR0 0x0000000B 0x07F00000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_ESR1 0x0000000B 0x00600600
R PRU_ICSS1_INTC_PRU_ICSS_INTC_ECR0 0x0000000B 0x07F00000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_ECR1 0x0000000B 0x00600600
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR0 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR1 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR2 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR3 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR4 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR5 0x0000000B 0x05040302
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR6 0x0000000B 0x00080605
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR7 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR8 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR9 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR10 0x0000000B 0x00000700
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR11 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR12 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR13 0x0000000B 0x00010700
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR14 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_CMR15 0x0000000B 0x00000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HMR0 0x0000000B 0x03020100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HMR1 0x0000000B 0x08060504
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HMR2 0x0000000B 0x00000009
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR0 0x0000000B 0x0000002A
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR1 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR2 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR3 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR4 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR5 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR6 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR7 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR8 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIPIR9 0x0000000B 0x80000000
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SIPR0 0x0000000B 0xFFFFFFFF
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SIPR1 0x0000000B 0xFFFFFFFF
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SITR0 0x0000000B 0xF80FFFFF
R PRU_ICSS1_INTC_PRU_ICSS_INTC_SITR1 0x0000000B 0xFF9FF9FF
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR0 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR1 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR2 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTCINTC_HINLR3 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR4 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR5 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR6 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR7 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR8 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HINLR9 0x0000000B 0x00000100
R PRU_ICSS1_INTC_PRU_ICSS_INTC_HIER 0x0000000B 0x000003FF
R PRU_ICSS1_PRU0_CTRL_PRU_ICSS_CTRL 0x0000000B 0x00000001
R PRU_ICSS1_PRU0_CTRL_PRU_ICSS_CTRL_STS 0x0000000B 0x00000690
R PRU_ICSS1_PRU0_CTRL_PRU_ICSS_CTRL_WAKEUP_EN 0x0000000B 0x00000000
R PRU_ICSS1_PRU0_CTRL_PRU_ICSS_CTRL_CYCLE 0x0000000B 0x00000000
R PRU_ICSS1_PRU0_CTRL_PRU_ICSS_CTRL_STALL 0x0000000B 0x00000000
R PRU_ICSS1_PRU0_CTRL_PRU_ICSS_CTRL_CTBIR0 0x0000000B 0x00000000
R PRU_ICSS1_PRU0_CTRL_PRU_ICSS_CTRL_CTBIR1 0x0000000B 0x00000000
R PRU_ICSS1_PRU0_CTRL_PRU_ICSS_CTRL_CTPPR0 0x0000000B 0x00000100
R PRU_ICSS1_PRU0_CTRL_PRU_ICSS_CTRL_CTPPR1 0x0000000B 0x00003000
R PRU_ICSS_MII_RT_RXCFG0 0x0000000B 0x00000015
R PRU_ICSS_MII_RT_RXCFG1 0x0000000B 0x0000001D
R PRU_ICSS_MII_RT_TXCFG0 0x0000000B 0x00400103
R PRU_ICSS_MII_RT_TXCFG1 0x0000000B 0x00400003
R PRU_ICSS_MII_RT_TXCRC0 0x0000000B 0xA301FA13
R PRU_ICSS_MII_RT_TXCRC1 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_TXIPG0 0x0000000B 0x000000B8
R PRU_ICSS_MII_RT_TXIPG1 0x0000000B 0x000000B8
R PRU_ICSS_MII_RT_PRS0 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_PRS1 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_RXFRMS0 0x0000000B 0x05F1003F
R PRU_ICSS_MII_RT_RXFRMS1 0x0000000B 0x05F1003F
R PRU_ICSS_MII_RT_RXPCNT0 0x0000000B 0x000000E1
R PRU_ICSS_MII_RT_RXPCNT1 0x0000000B 0x000000E1
R PRU_ICSS_MII_RT_RXERR0 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_RXERR1 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_RXFLV0 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_RXFLV1 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_TXFLV0 0x0000000B 0x00000000
R PRU_ICSS_MII_RT_TXFLV1 0x0000000B 0x00000000

For the ICSS_EMAC firmware load, please refer to:

#if defined(icev2AM335x) || defined(idkAM437x) || defined(iceAMIC110)
    if(PRUICSS_pruWriteMemory(ICSS_EMAC_testPruIcssHandle,PRU_ICSS_IRAM(0) ,0,
                          (uint32_t *) &pru_imem0_rev1_start,
                          &pru_imem0_rev1_end - &pru_imem0_rev1_start))
    {
        if(PRUICSS_pruWriteMemory(ICSS_EMAC_testPruIcssHandle,PRU_ICSS_IRAM(1) ,0,
                              (uint32_t *) &pru_imem1_rev1_start,
                              &pru_imem1_rev1_end - &pru_imem1_rev1_start))
        {
            retVal = TRUE;
        }
    }
#endif

And the binary is linked as:

-static ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_switch/bin/am437x/a9host/REV1/icss_switch_PRU0.bin ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_switch/bin/am437x/a9host/REV1/icss_switch_PRU1.bin

in CCS project ->CCS build->GNU linker->Misc.

Regards,
Garrett

Hello Garrett,

thank you for your reply.

>>> Except the SRSR0, SECR0 and HIPIR2, other register mappings looks OK. Please find the attached register dump when ICSS_EmacRxInterruptHandler is hit: eip_pru_reg.txt (...)

• I agree that the register dumps are looking equal except the SRSR0, SECR0 and HIPIR2. But your PRU1 seems to be in software reset (PRU_ICSS1_PRU1_CTRL = 0x00000001 ?!).
• The behavior of my SECR0 register also corresponds to the description: If event 20 is not issued, SECR0 is = 0x00000000, if event 20 is issued manually, SECR0 is = 0x00100000. But the original issue is still the same: The PRU does not issue event 20 automatically.

>>> For the ICSS_EMAC firmware load, please refer to: (...)

• Unfortunately, code snippet does not help. I already use this code for loading the EtherNet/IP firmware into the PRUs instruction memory. But the EtherNet/IP PRU firmware is provided in a different way (C-style byte array). The unit test uses pointers that are defined by the linker mapping, e.g. pru_imem0_rev1_start. So in other words:
  • Where does pru_imem0_rev1_start, pru_imem0_rev1_end, pru_imem1_rev1_start, pru_imem1_rev1_end link to? To the forst and last byte in corresponding binary file or to somwhere within the binary file?
  • Where does pru_dmem0_rev1_start, pru_dmem0_rev1_end, pru_dmem1_rev1_start, pru_dmem1_rev1_end link to? I could not find any binary file or binary data in the PDK sources.
• I just found the following entry in some linker command files:

SECTIONS
{
PRU0_REV1_IMEM : {
pru_imem0_rev1_start = .;
KEEP(*(PRU0_REV1_IMEM))
pru_imem0_rev1_end = .;
}
(...)

But this also seems to be a dead end, because I could not find a referenced sources (binary file or static image) for PRU0/1_REV1_IMEM/DMEM.

>>> And the binary is linked as:

• The linker entry you referenced ("-static ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_switch/bin...") does not seem to fit to the loopback unit test your have mentioned before (ICSS_EMAC_BasicExample_idkAM437x_wSoCFile_armtestproject). The loopback unit test seems to use the DUAL_MAC firmware ("-ccs.setLinkerOptions (...)  -static ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_dualemac/bin/(...)", see ICSS_EMAC_BasicExample_idkAM437x_wSoCFile_armtestproject.txt). Can you please clarify this? 

>>> Some open questions from my previous posts

• In the PRU_ICSS_INTC_HOHIR0/1 register, events 42 and 54 keep on pending after they appeared the first time. I would expect, that the PRU will clear them after issuing event 20. Is this correct? May this be a hint?
• ICSS_EMAC configuration: Which queue has to be selected as priority queue for the ICSS_EMAC?

Best regards

Stefan

Hello Garrett,

I have got another question related to the point of time when the PRU firmware is loaded into the instruction memory:

• Does it affect the proper operation of the PRU firmware (EtherNet/IP adapter), if the instruction memory is loaded before the ICSS_EMAC has configured the ICSS1?
• If yes, which is the correct point in time to load the firmware and disable, reset and enable the PRUs? 

It looks like the example initialization (ethernetip_adapter, unit tests, etc.) are doing the firmware loading at the end of the initialization. In our platform, we preload the firmware before initializing the ICSS_EMAC.

Best regards

Stefan

Stefan,

>>In the PRU_ICSS_INTC_HOHIR0/1 register, events 42 and 54 keep on pending after they appeared the first time. I would expect, that the PRU will clear them after issuing event 20. Is this correct? May this be a hint?

No, the interrupt is cleared in SECR0 through host driver, see the function ICSS_EmacClearIrq() in icss_emacDrv.c

HW_WR_FIELD32(((((ICSS_EmacHwAttrs*)icssemacHandle->hwAttrs)->emacBaseAddrCfg)->prussIntcRegs + CSL_ICSSINTC_SECR0),
CSL_ICSSINTC_SECR0_ENA_STATUS_31_0, ((uint32_t)1U) << intNum);

>>ICSS_EMAC configuration: Which queue has to be selected as priority queue for the ICSS_EMAC?

Please stick with switchEmacCfg->ethPrioQueue = ICSS_EMAC_QUEUE3; as shown in EIP main.c.

Let's ignore the loopback unit test for now as it appears to be not straight forward to port to your board. 

Regards,

Garrett

Stefan,

It really should not matter when the PRU firmware should be loaded and run...

Regards,
Garrett