• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1957 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.

RTOS/AM3356: PRU Ethernet frame receive problem

Mark Steinmetz
Intellectual 300 points
Part Number: AM3356
Other Parts Discussed in Thread: DP83640

Tool/software: TI-RTOS

Hello,

I am currently porting the PRU-ICSS-PROFINET-SLAVE 01.00.01.00 to a custom hardware platform. I am having a problem when trying to send an Ethernet frame to the platform.

When an Ethernet frame is sent, I do not see the ICSS_EmacRxInterruptHandler execute.

I was able to confirm that I am seeing the ICCS_EmacLinkISR execute when I plug and unplug the RJ45 Ethernet cable from the platform.

While using the debugger, I halt execution and examine the PRU ICSS SRSR0 and SRSR1 registers (as per SPRUHF8A). I believe these two registers report pending interrupts.

While halted, when I plug/unplug the Ethernet cable I see that SRSR1 (address 0x4a320200) goes from 0x0 to 0x200. The 0x200 corresponds to SYSTEM EVENT 41.

Both the SPRUHF8A document and the contents of the tiswitch_pruss_intc_mapping.h include file in the examples\profinet_slave directory seem to indicate that SYSTEM EVENT 41 is associated with the MMI_LINK0_EVENT (#define MMI_LINK0_EVENT 41). The #define for PRUSS_INTC_INITDATA also sets up SYSTEM EVENT 41 as CHANNEL7.

If, again using the debugger with execution halted, I send a PING to the platform, I see SRSR1 change from 0x0 to 0xc. In this case the 0xc correspond to SYSTEM EVENT 35 and SYSTEM EVENT 36.

The EVENT 35 and EVENT 36 do not seem to be the expected SYSTEM EVENTS -- at least by the #defines for PORT1_RX_EOF_EVENT (#defined as 42) and PORT2_RX_EOF_EVENT (#defined as 54).

I have checked the PRU_ICSS MII_RT register (0x4a326002c) and it is set to 0x1. This would seem to be correct and I should expect a PORT1_RX_EOF_EVENT or a PORT2_RX_EOF_EVENT when the PRU receives an Ethernet frame.

I am unsure how to proceed. Can you offer any suggestions as to how to determine what is going on?

　

I am using NDK 2.25.01.11 , PDK AM335x_1_0_6, SDK RTOS am335x_3_03_00_04 and PRU-ICSS-PROFINET-SLAVE 01.00.01.00.

　

　

Thanks.

 

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 43296 points
    Mark,

    From your detailed analysis, it seems the PORT1_RX_EOF_EVENT never happen due to the event 36 PRU0_RX_CRC. The CRC error event should block the ICCS_EmacLinkISR execution.

    Have you tried to run ICSS_EMAC loopback unit test to verify the packets can be transferred properly on your board? Also you can slightly modify the code to receive the packets from external traffic generator.
    If the loopback test passes, you can try to ping the board with NIMU ICSS EMAC example in the PDK, and see if you get the same CRC error.
    processors.wiki.ti.com/.../Processor_SDK_RTOS_ICSS-EMAC(DRIVER,FIRMWARE)
    processors.wiki.ti.com/.../Processor_SDK_RTOS_NDK

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Intellectual 300 points

    Garrett,

     

    The problem I am having with the PRU appearing not to see the received ENET frames is only happening in my current porting effort.   This porting effort is to use the latest versions of NDK, PDK, and PROFINET.

     

    I have an earlier version that does correctly receive and transmit ENET frames that is based on circa 2015 versions of NDK, PDK, PROFINET, etc.

     

    I performed another debugging exercise that consisted of debugging the working version, documenting the PINMUX setting for the PRU MII pins (0x44e108a0 through 0x443108d8) and the PRU CONFIG REGISTERS (0x4a326000 through 0x4a326054) and then comparing to the non working version.

     

    The PINMUX settings were all identical, but the PRU ICSS CONFIG registers had some differences:

     

     

    The PRU_ICSS_CFG SYSCFG  register (0x4a326004) contains a value of 0xa on the working version,   a value of 0x36 on the non working version.

     

    The PRU_ICSS_CFG CPCFG0  register (0x4a326008) contains a value of 0x3 on the working version,   a value of 0x1 on the non working version.

     

    The PRU_ICSS_CFG CPCFG1  register (0x4a32600c) contains a value of 0x3 on the working version,   a value of 0x1 on the non working version.

     

    The CPCFG0 and CPCFG1 register differences seem troubling to me based on the register field discriptions in SPRUHF8A:       a value of 1 sets the PRUx_GPI_MODE to “16-parallel capture mode” while a value of 3 sets the mode to “Mii_rt mode”.     Could this be a part of my problem?  

     

    The PRUSSDRVPruCfgInit function performs initialization of the CPCFG0 and CPCFG1 registers.   The registers are set to 0x1 or 0x3 based on the value of icss_version (set to 1 for icss_version >= 0x201).       I believe that icss_version is obtained by reading the PRU_ICSS_CFG REVID register (0x4a326000) – and for both the working and non working the value of the register is 0x47000000 – yielding an icss_version of 0x0

     

    Could this explain my problem receiving ENET frames?

     

    Also, is the SPRUHF8A-May2012-Revised in June 2013 the latest version – is the information within still accurate?   If there is a newer version and/or newer document would you please provide a link.

     

    Thanks,

     

    Mark

  • 0 in reply to Mark Steinmetz
    TI__Mastermind 43296 points
    Mark,

    The SYSCFG, CPCFG0/1 should be initialized as the working version - Enable OCP master ports, Mii_rt mode.

    You can find the up-to-date register definitions in AM335x TRM SPRUH73P - www.ti.com/lit/ug/spruh73p/spruh73p.pdf . The SPRUHF8 seems be discontinued as most of its contents is included in TRM and we shift PASM compiler to TI PRU compiler.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Intellectual 300 points
    Thanks Garrett,

    Thanks for the link -- do not know how I found SPRUHF8 -- probably google searching for something. Did not even think to look in SPRUH73.

    Another question: what version should I expect to see for the icss_version that is tested in the PRUSSDRVPruCfgInit function.

    I am guessing that another symptom of my problem is that the icss_version is not correctly reported.

    The version is read in PRUICSS_create --- I just used the debugger to confirm that I am reading a 0x47000000 from address 0x4a326000 in the new port.

    The way the code is written I would expect that I should read 0x47000201 or greater from address 0x4a326000.

    Thanks,

    Mark
  • 0 in reply to Mark Steinmetz
    TI__Mastermind 43296 points

    Mark,

    0x47000201 is expected only on Sitara AM57x family. I will find out the background of setting GPI mode (Mii_rt vs. 16-bit parallel capture) depends on icss_version internally. Have you tried to re-configure the SYSCFG/GPCFG0/GPCFG1 after PRUSSDRVPruCfgInit() and before executing program on PRU?

    Regards, Garrett

  • 0 in reply to Garrett Ding
    TI__Mastermind 43296 points

    Mark,

    Were you able to resolved the Ethernet frame receive issue after updating the SYSCFG/GPCFG0/GPCFG1?

    Regards, Garrett

  • 0 in reply to Garrett Ding
    Intellectual 300 points

    Hi Garrett,

    Thanks for the follow up!!!.    Unfortunately it did not appear to help when I updated the SYSCFG/GPCF0/GPCFG1.     I did confirm that I was getting good signals on the MII RXD and Clock lines so I believe that the PHY chip is correctly configured and working.

    My current effort is to do a "minimal" port from the PROFINET SLAVE example on the ICE2 board.    Unfortunately that proved to be more complicated than I had hoped and just yesterday I got it working well enough to determine that I am not even seeing the LINK interrupt.

    If you can offer any further suggestions as to what to look at to further troubleshoot the lack of the RX interrupt,  I feel that is my better path forward.

    Thanks,

    Mark

  • 0 in reply to Mark Steinmetz
    TI__Mastermind 43296 points
    Mark,

    What's the effort involved in porting the PROFINET 1.0.1 to your custom board? Would it be possible to upload here so we can help review? After you have the GPCFG register updated to Mii_RT, do you still see the same CRC error event? Instead of porting a minimal version of PROFINET slave to ICEv2 board, you might take the default one and step by step to compare the call flow between the ICE and your board?

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Intellectual 300 points

    Hi Garret,

    I have continued to work on this with my latest step being to do another minimal port of the ICEV2 example onto our platform.

    I was able to have our platform successfully respond to Ethernet PINGS after the minimal port.   I set a breakpoint in the ICSS_EmacRxPkInfo2 function and examined the RxPktInfo structure while processing the received ARP frame.   The RxPktInfo structure has PORT as 1 and QUEUE as 3.

    I then proceeded to a second step of porting related to the platform functional requirements.    The platform has two Ethernet ports but the requirement is that only one of the two be active at any time and that a jumper read during power up determines which of the two ports is to be active.     My test code only was attempting to use ICSS_EMAC_MODE_MAC1,    but ultimately I was planning to have the jumper decide between MAC1 and MAC2.

    I modified the main.c code to change ONLY  switchEmacCfg->portMask from ICSS_EMAC_MODE_SWITCH to ICSS_EMAC_MODE_MAC1 and again ran the ping test.     I observed the same results as I had seen earlier --   I saw link interrupts as I plugged/unplugged the Ethernet cable,  but did not see any RX interrupt.

    The changes I made are shown below.      By defining "WORKING" the code original code was included and this code did respond to PINGS.     When "WORKING" was not defined several lines of code were changed to ICSS_EMAC_MODE_MAC1.

    It seems that I have not done things correctly when I set  switchEmacCfg->portMask from ICSS_EMAC_MODE_SWITCH to ICSS_EMAC_MODE_MAC1.

    Several questions:

    1)   The PHY chip I am using is wired to PR1_MII0.    Is  ICSS_EMAC_MODE_MAC1 the correct choice?

    2)  Another option I could pursue is to leave the portMask set to ICSS_EMAC_MODE_SWITCH and to disable the unused PHY.   We are using the DP83640 PHY and setting BIT 10 of the PHY BMCR register isolates the PHY which I believe should effectively disable it.     Would this work?    Do you see any other problems or performance issues if this option is used?

    3) If configuring for MAC1 or MAC2,  do I need to use a different PRUSS_INTC_INITDATA structure verses the structure used for the SWITCH?    If so,  can you point me to the correct structure to use for MAC1 and MAC2.

    4)  I noticed a new version of the PRU ICSS PROFINET (wiki.ti.com/index.php/PRU_ICSS_Profinet) -- release 01.00.02  (using PROCESSOR-SDK-RTOS 04_02_09) with a release "FEB 2018".    Do you recommend using this release?

    Thanks for any help you can provide,

    Mark

  • 0 in reply to Mark Steinmetz
    TI__Mastermind 43296 points
    Mark,

    Though the dual mac mode (ICSS_EMAC_MODE_MAC1) is tested in standalone PDK ICSS_EMAC driver. It's recommend to align with default PROFINET configuration on port mode (ICSS_EMAC_MODE_SWITCH).

    1) Recommend to remain ICSS_EMAC_MODE_SWITCH.

    2) It should work with isolating the Port from the MII with the exception of the serial management. There is no performance issue.

    3) If you want to try dual mac mode, yes, the PRUSS_INTC_INITDATA structure is different between SWITCH and DUAL MAC, see tiemac_pruss_intc_mapping.h in pdk_am335x_1_0_9\packages\ti\board\diag\icss_emac\src

    4) Yes, recommend to use the new release 1.0.2 which is on top of latest Processor SDK RTOS 4.2 and available in a few days.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Intellectual 300 points
    Thanks for the support Garrett. Where will I be able to find release 1.0.2 when it becomes available?

    Mark
  • 0 in reply to Mark Steinmetz
    TI__Mastermind 43296 points

    Mark,

    The release 1.0.2 will be published at www.ti.com/.../PRU-ICSS-INDUSTRIAL-SW
    We are working with CM/web team to get this online very soon.

    Regards,
    Garrett