Hello! Does anyone has some work done porting the Networkinterface.c for this processor family? I’m trying to follow the implementation steps made by NXP in the lwip port, but I don’t know if it will take me to anyware.

As far as I know, nobody has published a FreeRTOS+TCP driver for LPC546xx yet. If you have the energy and if you are brave enough: you can develop it yourself. If you like, you can contact me directly ( hein [at] htibosch [dot] net ) There are several help pages on freertos.org, and also you can look at the existing drivers.

In the freertos pages I am right now 🙂 NXP has the e Ethernet controller driver and even the PHY driver (LAN8720A, in this case). I think that most of the hard work is done and right now it must be matter of integration. I’m a little bit lost in trying to understand how this integration was done with the lwpi and how the it was done with the LPC18XX

Hello gain! I have a kind of mix between a “copy bytes” and a “zero cropy bytes” driver. In the receive frame mechanism I’m using the ENET driver and it is copying bytes. In the send mechanism, I’m just passing the pucEthernetBuffer to TX DMA buffer (the ENET send driver is using a zero copy mechanism). I’m testing it, and it seems to be working. At least the DHCP is working. Regarding the DHCP, it seems that is not being called with the FreeRTOSIPInit but it is being called with a cable disconnect/connect event (with the FreeRTOSNetworkDown()). Can anyone confirm this? ~~~ SDRAM data bus check OK. SDRAM address bus check OK Tested 8388608 SDRAM bytes with 0 errors Serial running at 110215264Hz SDRAM running at 110MHz CPU running at 220MHz Board Booted OK FreeRTOSIPInit prvIPTask started FreeRTOSPHYInit: Starting FreeRTOS_PHYInit: OK IP Address: 192.168.1.30 Subnet Mask: 255.255.255.0 Gateway Address: 192.168.2.1 DNS Server Address: 192.168.2.1 FreeRTOSPHYISR: ENET Deinit FreeRTOSPHYInit: Starting FreeRTOSPHYInit: OK prvInitialiseDHCP: start after 250 ticks vDHCPProcess: discover vDHCPProcess: discover vDHCPProcess: timeout 10000 ticks vDHCPProcess: offer 0xC0A8026A ip vDHCPProcess: reply 0xC0A8026A ip vDHCPProcess: offer 0xC0A8026A ip vDHCPProcess: acked 0xC0A8026A ip IP Address: 192.168.2.106 Subnet Mask: 255.255.255.0 Gateway Address: 192.168.2.1 DNS Server Address: 192.168.2.2 ~~~

Problem solved -> Note: The random number generator must be seeded before the TCP/IP stack is started, so before FreeRTOS Init() is called. as simple as that

Sorry about that, but you are right: when the random generating function ipconfigRAND32() returns zero, that is considered as an error. That is a very old piece of code. You can also argue that zero is a valid random number. For now, could you adapt your ipconfigRAND32() so it’ll never return zero? It is very important to use a random seed, each time after booting. And also it would be better if you have a true source of randomness, in stead of some predictable algorithm.

No worries. It is good to be “forced” to dig in the code. It gives a better understanding about how it works. Regarding the random generating function, now I’m using the hardware assisted RNG.

Hello! I’m still here , in this fight 🙂 Sometimes I’m receiving this “warning”: SACK[7,39184]: optlen 12 sending 3160 – 3236 In this specific case, what should be 3 received messages, becomes only one big and incomplete message: Sent data: msg1: 0x01 0x03 0x00 0x01 0x00 0x08 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x01 0x01 0x00 0x08 0x44 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x01 0x00 0x08 0x11 0x22 0x33 0x44 0x00 0x00 0x00 0x53 msg2: 0x01 0x03 0x00 0x01 0x00 0x08 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x01 0x01 0x00 0x08 0x44 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x01 0x00 0x08 0x11 0x22 0x33 0x44 0x00 0x00 0x00 0x54 msg3: 0x01 0x03 0x00 0x01 0x00 0x08 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x01 0x01 0x00 0x08 0x44 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x01 0x00 0x08 0x11 0x22 0x33 0x44 0x00 0x00 0x00 0x55 Received data: Just one big message: SACK[7,39184]: optlen 12 sending 3160 – 3236 lTCPWindowRxCheck[39184,7]: retran 3132 (Found 76 bytes at 3160 cnt 1) ETH len 104 04: 05: 06: 07: 01: 01: 00: 08: 44: 55: 00: 00: 00: 00: 00: 00: 02: 01: 00: 08: 11: 22: 33: 44: 00: 00: 00: 53: 01: 03: 00: 01: 00: 08: 00: 01: 02: 03: 04: 05: 06: 07: 01: 01: 00: 08: 44: 55: 00: 00: 00: 00: 00: 00: 02: 01: 00: 08: 11: 22: 33: 44: 00: 00: 00: 54: 01: 03: 00: 01: 00: 08: 00: Anyone knows why is this happening?

Cristiano, it would be very helpful you can run a program like WireShark and let it produce a (compressed) PCAP file. You can attach that to your post. As you probably know, a SACK is a selective acknowledgement. It is issued as soon as a previous packet is missing. It helps the sender to do a specific retransmission. SACK’s should not occur on a LAN, only on the Internet. Well, unless the LAN is extremely big and busy.

Hello Hein! Thank you for your answer. I didn’t know that about SACK, but at least now I read a little bit aout it. Ok, now I have the TCP dump and I isolated the segment of one SACK occurrence. It seems that I have two problems: 1 – the messages are being put correctly in the wire but somehow my LPC MCU is not seeing it 2 – Because the MCU is not seeing it, SACK is being used in order to get back the missing packets but the out-of-order generated message is not correct. lost messages are: 0x01 0x03 0x00 0x01 0x00 0x08 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x01 0x01 0x00 0x08 0x44 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x01 0x00 0x08 0x11 0x22 0x33 0x44 0x00 0x00 0x01 0x7B 0x01 0x03 0x00 0x01 0x00 0x08 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x01 0x01 0x00 0x08 0x44 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x01 0x00 0x08 0x11 0x22 0x33 0x44 0x00 0x00 0x01 0x7C and 0x01 0x03 0x00 0x01 0x00 0x08 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x01 0x01 0x00 0x08 0x44 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x01 0x00 0x08 0x11 0x22 0x33 0x44 0x00 0x00 0x01 0x7D

Cristiano, thanks for sending the PACP’s. I am looking at the large PACP, because it starts with the SYN/ACK. Packet 575 ACK: 5820 ( correct acknowledgement ) Packet 577 receives SEQ 5820 with length 38 Next = 5858 ( still Ok ) … Here it seems to receive 10 bytes, or at least the ACK counter is increased by 10 Packet 578 ACK : 5830 which should be 5858 Packet 579 SACK : 5830 : seen packet 5820 with length 38 And then there is a “TCP Out-Of-Order” packet that satisfies the device. But that is not what we want. I am puzzled, why is the ACK counter is incremented with 10? It doesn’t look there has been an invisible packet. The value of the ACK is stored in host-endian format: pxSocket->u.xTCP.xTCPWindow.rx.ulCurrentSequenceNumber The ACK field is being set here: ~~~ /* Tell which sequence number is expected next time */ pxTCPPacket->xTCPHeader.ulAckNr = FreeRTOS_htonl( pxTCPWindow->rx.ulCurrentSequenceNumber ); ~~~ Would it be possible to trace the variable of ulCurrentSequenceNumber ?

Can I simply put a printf in lTCPWindowRxCheck? ~~~ As a side-effect, pxWindow->ulUserDataLength will get set to non-zero, if more Rx data may be passed to the user after this packet. */

    ulCurrentSequenceNumber = pxWindow->rx.ulCurrentSequenceNumber;
    PRINTF("%lun", ulCurrentSequenceNumber);

~~~ I’m attaching a zip with the full port. I’m afraid that I’m doing something wrong in the port and because of that I’m misinforming you and taking your time.

Hello! Here it is the ulCurrentSequenceNumber trace in the correct place ~~~ /* Tell which sequence number is expected next time */ pxTCPPacket->xTCPHeader.ulAckNr = FreeRTOS_htonl( pxTCPWindow->rx.ulCurrentSequenceNumber ); PRINTF(“%c %lun”, who, pxTCPWindow->rx.ulCurrentSequenceNumber); ~~~ A – prvTCPReturnPacket is called in prvSendData B – prvTCPReturnPacket is called in prvTCPSendPacket C – prvTCPReturnPacket is called in prvTCPSendRepeated D – prvTCPReturnPacket is called in prvTCPSendReset E – prvTCPReturnPacket is called in xTCPSocketCheck

Curious, in the trace there is also an unexpected increase of 10 : ~~~ C 2485788140 A 2485788178 C 2485788178 C 2485788178 A 2485788188 // 10 bytes increase lTCPWindowRxCheck[48340,1666]: seqnr 348 exp 358 (dist -10) SACK to 386 ~~~ We’re getting very much into details now. Would you mind sending me an email so we can discuss thing more directly? My address is hein [at] htibosch [dot] net