Mac address filter bug has me stumped

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
gerrykurz
XCore Addict
Posts: 204
Joined: Sun Jun 01, 2014 10:25 pm

Mac address filter bug has me stumped

Post by gerrykurz »

Here is the scenario:

I have an application with two instances of the real time ethernet mac.

One of them has multiple rx clients, with multiple mac address filters and at this point seems to be working just fine.

The second one has only one rx client again with multiple mac address filters and one of the filters is not working. This mac (and port) is connected to an AVB Endpoint Development board and by doing debug_printf's, I have confirmed that this board is receiving and responding to 1722.1 messages. The issue is that the mac is picking up the 1722.1 ADP destination broadcast address but is not picking up the 1722.1 messages that are being sent to the AVB controller with a specific mac address.

My issue is that I could change the mac code to forward all packets to my client but this would affect the working clients on the other instance.

Any ideas how I could enable promiscuous mode on one instance and not the other?

I have worked through a number of issues with the ethernet and tsn libraries on my own this week but I really stuck on this one.

Please help if you can.....thanks Gerry
Last edited by gerrykurz on Mon Jul 20, 2015 7:39 pm, edited 1 time in total.


User avatar
gerrykurz
XCore Addict
Posts: 204
Joined: Sun Jun 01, 2014 10:25 pm

Post by gerrykurz »

Never mind, I am not going to try and debug this right now but I had an idea of using a tile number flag to have different instances behave differently when running on different tiles.

But rather than do the work involved in this, I am going to try and get my packets using ethertype filtering instead.
User avatar
gerrykurz
XCore Addict
Posts: 204
Joined: Sun Jun 01, 2014 10:25 pm

Post by gerrykurz »

Well as it turns out, ethertype filtering was not the answer and I did have to implement tile dependent debugging.

Which led to the apparent problem, something to do with the way rx packets are queued in the server....

Still working on it