PRU-ICSS-INDUSTRIAL-SW: Configuration related to Firmware from emac driver
Part Number: PRU-ICSS-INDUSTRIAL-SW
I am developing an Ethernet driver for PRU-ICSSG (SR 2.0) using dual mac firmware for AM6548 chip based on a proprietary RTOS.
I am observing a corruption in the packet during transmission. I am trying to send an ICMP response (via ICSSG2 port 0) as below:
------ PACKET START -------0x84 , 0xaf , 0xec , 0x73 , 0x1 , 0xf3 , 0x0 , 0x11 , 0x22 , 0x33 , 0x44 , 0x55 , 0x8 , 0x0 , 0x45 , 0x0 , 0x0 , 0x3c , 0x0 , 0x1 , 0x0 , 0x0 , 0x40 , 0x1 , 0xef , 0x6c , 0xc0 , 0xa8 , 0x5 , 0x1 , 0xc0 , 0xa8 , 0x5 , 0x2 , 0x0 , 0x0 , 0x54 , 0x7e , 0x0 , 0x1 , 0x0 , 0xdd , 0x61 , 0x62 , 0x63 , 0x64 , 0x65 , 0x66 , 0x67 , 0x68 , 0x69 , 0x6a , 0x6b , 0x6c , 0x6d , 0x6e , 0x6f , 0x70 , 0x71 , 0x72 , 0x73 , 0x74 , 0x75 , 0x76 , 0x77 , 0x61 , 0x62 , 0x63 , 0x64 , 0x65 , 0x66 , 0x67 , 0x68 , 0x69 , ------ END START -------
I have configured the tx port queue for the firmware as 0x70000000 (MSMC SRAM region). After UDMA enqueued the packet to the ring, I have checked the contents of the tx port buffer region. I performed a Cache invalidation of the tx port queue regioin found that the buffer is transferred properly to the tx port queue region, from 0x70000080.
Please check attached image
But the packet was sent out corrupted on the wire.
The Ethernet header was corrupted , first 2 octets changed from 0x84 0xaf to 0x80 0xab, the packet type got changed from 0x0800 to 0x0000. Also the body of the packet was corrupted.
Also, I have seen another issue in the reception path, the ARP packets does not seem to be forwarded to the driver by the firmware. So, I added static ARP entries to the host PC and the the target device and tried to ping, and got the above behavior. The RX ICMP packet is correctly forwarded to the driver. Also other broadcast packets are received. I have configured the firmware based on the emac driver (v5).
Could you please provide some clues on how to debug the above TX and RX (ARP packets) issues? Is there any way to enable any firmware logs. Any help will be highly appreciated.
Have you verified your application with tx/rx packet in TI-RTOS before moving to the proprietary RTOS? Let me reach out to the firmware developer to see any insight to the issues you are observing.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Garrett Ding:
Thank you for your feedback. No, I haven't tried it in TI RTOS, I will give it a try.
Thank you once again, for your help. A feedback from the firmware team will be really helpful!
The problem with the TX packets is resolved. The tasks corresponding to "Board_init(BOARD_INIT_ICSS_ETH_PHY);" was missing. I had included this code in SBL instead of the driver, but the SBL that I was using was not the updated one. Now I can send and receive ICMP packets without corruption.
However, the issue with the reception of ARP packets still remain. I think it is due to the minimum length of packet supported by the firmware. An ARP packet is 42 bytes, padded to 60 bytes (+ 4 bytes CRC). It probably does not meet the minimum requirement by the dual mac firmware.
To confirm the above, I used the test program in PDK "pdk_am65xx_1_0_7\packages\ti\board\diag\icssg_emac\src\icssg_emac_test.c" which sends out packets of length 64 bytes (BOARD_DIAG_ICSS_EMAC_TEST_PKT_SIZE) from one interface and receives the same on another interface (64 bytes of packet + 4 bytes of CRC). I changed the macro "BOARD_DIAG_ICSS_EMAC_TEST_PKT_SIZE" in "pdk_am65xx_1_0_7\packages\ti\board\diag\icssg_emac\src\icssg_emac_test.h" to 60 bytes (same length as a normal ARP request packet) and sent out the packet, but the packet was not received on the other interface, and the loopback test failed.
Could you please kindly discuss with the firmware team about the above? I think the minimum size of the packet to be received should be 60 bytes (excluding CRC).
In reply to Debarun Roychowdhury:
The firmware developer was out of office last week. I will update you once I get confirmation about the packet size limitation.
The RX_EOF task checks if packet >= 64 bytes (otherwise drops it), see
pdk_am65xx_1_0_7\packages\ti\drv\emac\firmware\icss_dualmac\src\rxl2_txl2 line 879:
rx_eof_done: ; check for runt packet qble rx_eof_done_b, GRegs.rx.b.pkt_len, 64 set r31.t18 ;reset RX_fifo
Thank you very much for the feedback, it really helps!
I want to change it to 60 bytes and compile the source to generate the firmware binaries (under bin and bin_pg2). Is there any guide for the steps?
Is there any reason why the minimum size is set to 64 bytes? Generally, the minimum size of a frame is 60 bytes and with CRC it is 64 bytes. But with this setting, the size becomes 64 bytes of frame + 4 bytes of CRC. If the minimum size is not 60 bytes a lot of packets are being dropped, for example during the establishment of a telnet session the below happens:
The 64 bytes in the code should have CRC included already. But you can try to modify the firmware and build with the command: pdksetupenv.bat and then go to pdk_am65xx_1_0_7\packages\ti\drv\emac\ and run gmake.
Thank you for your feedback, I highly appreciate it!
I have tried compiling the source using gmake, the "pdk_am65xx_1_0_7\packages\ti\drv\emac\firmware\icss_dualmac\bin" is getting created, but "pdk_am65xx_1_0_7\packages\ti\drv\emac\firmware\icss_dualmac\bin_pg2" is not getting created. Could you please kindly let me know how to generate the firmware binaries for SR 2.0, as I am testing on SR 2.0 board.
Garrett DingThe 64 bytes in the code should have CRC included already.
As I had mentioned in the previous post:
" To confirm the above, I used the test program in PDK "pdk_am65xx_1_0_7\packages\ti\board\diag\icssg_emac\src\icssg_emac_test.c" which sends out packets of length 64 bytes (BOARD_DIAG_ICSS_EMAC_TEST_PKT_SIZE) from one interface and receives the same on another interface (64 bytes of packet + 4 bytes of CRC). I changed the macro "BOARD_DIAG_ICSS_EMAC_TEST_PKT_SIZE" in "pdk_am65xx_1_0_7\packages\ti\board\diag\icssg_emac\src\icssg_emac_test.h" to 60 bytes (same length as a normal ARP request packet) and sent out the packet, but the packet was not received on the other interface, and the loopback test failed."
When the "BOARD_DIAG_ICSS_EMAC_TEST_PKT_SIZE" is set to 64 for TX from interface x, the x+1 interface receives 68 bytes. The function "emac_pkt_too_big" invoked from "emac_poll_rx_pkts" in the RX path, subtracts 4 bytes of CRC and modifies the length of the received frame to 64 bytes from 68 bytes, which means the 4 bytes of CRC were appended by the firmware in the TX path. But when I change "BOARD_DIAG_ICSS_EMAC_TEST_PKT_SIZE" to 60 bytes (the firmware should have added 4 bytes of CRC making the length of the frame to 64 bytes), the packets are no longer received and the loopback test fails. But ideally, the packet should have been received as the total length is 64 bytes. This means the firmware checks the length excluding the CRC. It will be very helpful you can discuss this with the firmware team. (Please note the test was run with the PDK source itself, and not with my code. Also, I am testing on SR2.0, not SR1.0)
OK, let me find out why bin_pg2 is not created. In the mean while, can you please check the ICSSG_RX_FRMS0/1 register configuration?
Thank you for your help.
Garrett DingIn the mean while, can you please check the ICSSG_RX_FRMS0/1 register configuration?
Both the registers are set to 0x05f1003f. That is the min value seems to be specified as 0x3f + 1 = 64 bytes after SFD including CRC.
I also checked that, MII_RT_RX_ERR0/1 are not set, even when 60 bytes frames are sent to the board (example ACK of telnet connection).
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.