AM3357 PRU-ICSS dont send DHCP discover frames

Hi Damian,

I will forward this to the Industrial SDK team.

Hi Damian,

Which application are you using? Can you please verify whether the function TxPacketEnqueue() is returning success(0).

The firmware doesnot check broadcastEnable flag from PHY_DEV structure. So you can rule out the possibility. Are there any changes in the NDK configuration in the application?

Regards,
Prajith

Hi Prajith,

Im using the Ethernet/IP Adapter application with the Molex stack v3.3. TxPacketEnqueue is returning with success and even updates the statistics which say I have sent some packets.

Which changes in the NDK configuration do you mean? I just rebuilt the NDK stack for more debug informations. And the configuration "app.cfg" is nearly untouched. I only increased the heap size and set some compiler options for SYS/BIOS for a better debugging. For testing I tried to use the module "ti.ndk.config.DhcpClient" but thats not the problem I guess. I think the PRU-ICSS is missing something in its initialization or something like that.

Meanwhile I was afraid the PHY isnt properly initialized but the link status is recognized correct while the device is trying to send its DHCP frame

Regards,
Damian

Edit:
I recognized in this moment the switch from one port to the other doesnt work neither. Regardless whether theres a static IP or not.

Damian,

Can you check the Speed and duplexity settings of the PHYs . Are they different for the two PHYs?

Also what version of ISDK are you using?

Regards,
Prajith

Hi Prajit,

you have been absolutely right. I tested the switching ability with a 10Mbit half-duplex device and was connected to a 100M fullduplex net. So the switch is working correct even while waiting for a IP from the DHCP when I connect a proper device to the second port.

Im using the SDK 1.1.0.5. I checked the release notes on 1.1.0.6 and didnt seem relevant...

Regards,
Damian

Damian,

             Are you seeing any link activity( Link Led blink) after the TxPacketEnqueue function in executed. There is a possibility that we are sending out error packets and it is getting dropped at the other side. Is it possible to connect any Packet capture/analyzer device and confirm this scenario?

            Can you share the memory dump form CCS starting from location 0x4a303ea0 before and after TxPacketEnqueue gets called?

Regards,

Prajith

Prajith,

sorry we dont have any device which is able to capture error frames. But I checked the TX-lines between Sitara and PHY, and I can see some activity. It seems the frames are send every 3 seconds so it would match to the DHCP frames.

Sorry I didnt get how to attach files, so I post some pics

At reset:

Before TX:

after TX:

Thank you for your efforts

Damian

Damian,

Here the entry at 0x4a303ed8 and 0x4a303eda are the read and write pointers of Port 1 Queue 4. It is changed from 0x10ac to 0x10f8 . It indicates that the firmware has detected the packet and sent it out. Here total bytes sent out will be ( 0x10f8- 0x10ac) /4 * 0x20 = 608u bytes. I don't see anything wrong here.

If you put break point in TxPacketEnqueue and allow only single packet and get the memory dumb , you can compare the number of bytes enqueued by driver and the number sent out by firmware.

Still not able to understand why you cant see it in wire.

Regards,
Prajith

Hi Prajith,

"lengthOfPacket" inside of TxPacketEnqueue  is 590 byte every time. I checked the frame content with wireshark and its correct.

So there are two open questions:

1. Are the frames padded to a 32byte alignment every time or how could you explain the 18byte difference?

Preamble = 7byte

SFD = 1byte

(Vlan-tag = 4byte?)

FCS = 4byte

- Is it possible to get the frame check sequence of the frames?

Regards,

Damian

Damian,

The Rx and Tx Queue is divided in 32 bytes block. So even if the size of the packet is 590 , the read and write pointer will be moved in a block of 32. Hence the value 608. Here the PRU gets the length from the buffer descriptor and it will send out 590 bytes only not 608.

Its my mistake that i mentioned 608 bytes of data will be transferred. Hope this helps.

Regards,
Prajith

Hi Prajith,

thanks for the clarifcation. But unfortunately we still have no idea how to fix this problem. Do you have any idea what to check to find the root of this problem. I think its something with the communication to the PHY or even the MAC. Is it possible to check this interfaces? Maybe reading out the FCS for a ETH-frame or something like that...

Regards,
Damian

Damian,

As you see activity led blinking once the TxPacketEnque is exectued, it seems some packets are being sent out (may be error packets). In order to debug further, you might need to use a packet analyzer to capture the frame.

One more thing you ca n check is for any differences in init codes (Phy or MII) between DHCP and static IP mode applications.

Regards,
Prajith

Hi Prajith,

i dont know if the activity led is blinking because of the sent packet but it seems so. Unfortunately we dont have a analyzer to check the packets so I have to fix it another way.
Is it possible that it could be a clock issue? Yesterday I recognized the clocks seem to run on a wrong frequency. For example I have problems with the UART baudrate which deviate about 4%. But I dont understand why because I thought the bootloader is configuring the clocks in dependence to the sysboot pins. But it would fit to the hardware change we made changing the oscillator from 24MHz to 25MHz which is a change of 4%. Do you see a correlation?

Regards,
Damian

Damian

Glad to know the issue is fixed

Regards,
Prajith