microcris wrote on Monday, March 11, 2019:
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.
heinbali01 wrote on Monday, March 11, 2019:
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.
microcris wrote on Monday, March 11, 2019:
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
microcris wrote on Wednesday, March 27, 2019:
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 FreeRTOS_IPInit but it is being called with a cable disconnect/connect event (with the FreeRTOS_NetworkDown()). 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
FreeRTOS_IPInit
prvIPTask started
FreeRTOS_PHYInit: 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
FreeRTOS_PHY_ISR: ENET Deinit
FreeRTOS_PHYInit: Starting
FreeRTOS_PHYInit: 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
microcris wrote on Saturday, March 30, 2019:
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
heinbali01 wrote on Sunday, March 31, 2019:
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.
microcris wrote on Monday, April 01, 2019:
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.
microcris wrote on Monday, May 06, 2019:
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?
heinbali01 wrote on Tuesday, May 07, 2019:
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.
microcris wrote on Tuesday, May 07, 2019:
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
heinbali01 wrote on Tuesday, May 07, 2019:
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 ?
microcris wrote on Tuesday, May 07, 2019:
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("%lu\n", 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.
microcris wrote on Wednesday, May 08, 2019:
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 %lu\n", 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
heinbali01 wrote on Thursday, May 09, 2019:
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