XTCP v6.0.0 example Topic is solved

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
Redeye
Experienced Member
Posts: 99
Joined: Wed Aug 03, 2011 9:13 am

XTCP v6.0.0 example

Postby Redeye » Tue Jul 10, 2018 4:42 pm

I'm struggling to track down what looks like an ARP bug in v4.0.2 of the XTCP library. It's incredibly difficult to reproduce (it requires multiple XMOS devices and TCP clients) but it hangs the whole ethernet stack so it's a fairly high priority.

I can see that XTCP has been updated to v6.0.0 some time ago, but as far as I can see none of the example documentation has. Can anyone point me in the direction of a working example application using the current v.6.0.0 code to help me port my current application to the new API?
View Solution
User avatar
mon2
XCore Legend
Posts: 1218
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Tue Jul 10, 2018 11:05 pm

Found a keyword match of 6.0.0 for the following:

https://github.com/xmos/lib_xtcp/tree/m ... 1_udp_demo

https://github.com/xmos/lib_xtcp/blob/m ... N00121.rst

We are in development of a new Ethernet line of devices but openly reviewing to use Wiznet TCP/IP devices to ease this migration. Next issue is SSL/TSL support.
Redeye
Experienced Member
Posts: 99
Joined: Wed Aug 03, 2011 9:13 am

Postby Redeye » Wed Jul 11, 2018 9:29 am

Thanks, not sure how I've managed to miss that. If anyone at XMOS sees this - it would maybe be a good idea if AN00121 was updated, seeing as it's over a year since v6.0.0 was released.

I can see the appeal of the Wiznet devices. On cost there's probably not a lot in it, but we put the TCP/IP stack on the XMOS mainly just so that if we get a problem like this, at least we can run the code and see the problem. However, having used the FTDI devices in the past and suffered the problems of bugs in their drivers which cause problems with our products I'm perhaps a bit over-cautious.
ozel
Active Member
Posts: 36
Joined: Wed Sep 08, 2010 10:16 am

Postby ozel » Thu Jul 12, 2018 11:16 pm

also see this repo where v7 seems to be prepared:
https://github.com/jh14778/lib_xtcp

The v7 API is changed again, but really for the better.
Although I believe I'm also experiencing sometimes strange ARP behaviour with this version which is very hard to debug.

In my opinion, having a native TCP stack is really important. Personally, I would not consider network 'co-processor' solutions like WizNet, but ESP32 seems to be an interesting candidate as a drop in replacement for wired ethernet phys because they feature a MII interface!
Redeye
Experienced Member
Posts: 99
Joined: Wed Aug 03, 2011 9:13 am

Postby Redeye » Fri Jul 13, 2018 8:43 am

Interesting. It has to be said that the repeated API changes are a pain - moving my code from v4 to v6 is quite a bit of work. If it's going to change again for v7 that's pretty annoying.

What I know about the ARP problem is this :

Using v4 XTCP with UIP, if you have 4 or more XMOS devices running the same code and you try to connect to them all with a PC at the same time, you get a kind of "ARP storm" as they all send ARP broadcast messages which they all then received then all send more ARP broadcast messages until they get the ARP reply from the PC. This "ARP storm" often crashes the ethernet rx code on one or more of the XMOS devices and the only way to recover them is to reboot. The crash is happening in the ethernet rx code, not the XTCP thread, though exactly why eludes me at the moment as this is very time consuming and difficult to reproduce while running the code on the debugger.
User avatar
mon2
XCore Legend
Posts: 1218
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Fri Jul 13, 2018 10:44 am

OMG...same issue from a year ago?

viewtopic.php?t=5999
http://www.xcore.com/viewtopic.php?t=5999


Hence raises our justification to consider to stitch the Wiznet W5500 over SPI to offload to a proven TCP/IP stack in hardware. Positives are that it is proven by millions of users. Negatives include slower throughput due to SPI master speed so may not be practical for audio and extra logic and expense.

What if you attempt the same setup with multiple say STM32 mbed enabled boards running TCP/IP? Or multiple W5500-EVBs? That is our current lab setup to evaluate the W5500 and later will stitch to XMOS via SPI or parallel bus. There are some articles to use the same with DMA on STM32F4. We are evaluating the STM32H7 now due to the advertised 133 mhz spi bus speed as master or slave.

Assuming you are reviewing with Wireshark?

With Wiznet we have some factory support access and esp32 looks promising but is more user supported aside from volume sales. We started with them years ago when they were new on the market and the design was being reverse engineered and most docs were in Chinese.
Redeye
Experienced Member
Posts: 99
Joined: Wed Aug 03, 2011 9:13 am

Postby Redeye » Tue Jul 17, 2018 4:05 pm

Yes, it looks like it's the same issue. After quite a lot of investigation it looks like the bug is actually in the MII code, not the XTCP. I've logged the bug as a support ticket so let's see if XMOS respond - the issue has been logged on the Github repository for over 18 months without any response.

Who is online

Users browsing this forum: No registered users and 16 guests