• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 1176 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Multicast on 6678 (again...)

OH
Intellectual 260 points

Hi

I had some trouble a while ago regarding multicast, which resulted in this thread: http://e2e.ti.com/support/embedded/bios/f/355/p/247796/868873.aspx

The actual problem, joining a multicast group, was solved (I think, since setsockopt returns fine), but I still cannot receive anything using multicast.

I have the same code for sending/receving using multicast on a 6678 board and a Linux workstation.

Sending from the 6678 board and receiving on the Linux computer works fine, but if I try to do the opposite nothing reaches my software.

The only "diagnostics" I know about is looking in the STATSA and STATSB registers, and what I can see is that the STATSB RxMCastFrames matches the STATSA TxMCastFrames. Does that mean anything?

I'm having trouble analysing the STATS registers. I'm also having trouble finding out how to proceed. Any hints on how to discover how far the actual data gets?

For the network part, I have used the helloWorld example as a starting point, and I haven't changed just about anything I can relate to this problem.

Other than that, I'm using a C6678, NDK 2.21.01.28, SYS/BIOS 6.34.04.22 and MCSDK 2.01.02.05 (PDK 1.1.2.5). 

 

  • 0
    TI__Mastermind 45025 points

    Hi OH,

    It sounds like you've done everything correctly from the NDK side of things.  Oftentimes, however, it is also necessary to allow the reception of multicast frames at the driver level.  So my first suggestion is to ensure that the driver is properly enabled for multicast, so that frames are just getting dropped there.

    The next thing you can try is in the stack itself.  You can check to see if the multicast frames are reaching into the IP layer and also IGMP itself.  If the multicast packet is not being dropped by the driver, the driver should pass it up the stack via the NIMU layer (this is the "glue" that connects the EMAC driver to the rest of the stack).  NIMU will check the packet type, and it should pass the packet up to the IP layer.

    The IP layer should see that the packet is multicast, and then pass it to IGMP. IGMPInput() should handle the multicast packet.

    So what you can do is check that the packet is reaching all of these places:

    1. Verify the packet is passed from the driver into the stack via NIMU
      1. file: ti/ndk/stack/nimu/nimu.c
      2. function: NIMUReceivePacket()
      3. should hit case statement for IP and call IPRxPacket() (around line 284)
    2. Verify the packet is passed to the IP layer
      1. file: ti/ndk/stack/ip/ipin.c
      2. function: IPRxPacket()
      3. should hit call to IGMPInput() around line 451)
    3. Verify the packet reaches IGMP
      1. file: ti/ndk/stack/igmp/igmp.c
      2. function: IGMPInput()
      3. set break points as appropriate to debug

    If you don't even see the packet reaching the NIMU layer, then the driver may be dropping it.

    Steve

  • 0 in reply to Steven Connell
    Intellectual 260 points

    Thanks for the reply.

    I have to admit that I don't know exactly what the drivers are, that are supposed to hand the packages to NIMU. I was under the impression that what was between NDK and hardware was NIMU, but obviously I was wrong.

    As I said, the setup stuff is reused from the HelloWorld example. Is there a way to pass parameters to enable multicast, or do you mean that the drivers (which I don't know about) has to be recompiled with multicast enabled?

    /OH

  • 0 in reply to OH
    TI__Mastermind 45025 points

    OH,

    Unfortunately I won't be able to help you much with the driver configuration for the 6678.  You may need to refer to EMAC hardware guide for the 6678.  I believe this is it:

    http://www.ti.com/lit/ug/sprugv9b/sprugv9b.pdf

    I also found this thread which seems similar.  It may provide some hints, however it doesn't look like it was ever resolved:

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/199755.aspx?pi74271=2

    Steve

  • 0 in reply to Steven Connell
    Intellectual 260 points

    Ok, thanks anyway.

    I've also found the thread you linked to, and I've looked into the ALEPORT stuff mentioned there and to me it looks ok (as far as I can tell...)

    Anyone out there (TI employee or not) who have a working multicast environment and can help me with some hints? 

    Since my application had the HelloWorld application as a starting point, I would be interested in hearing if anyone have converted the HelloWorld example to handle multicast?

    /OH

  • 0 in reply to OH
    TI__Mastermind 45025 points

    OH,

    Have you checked the EMAC stats registers as described in that thread?

    Do you see that multicast packets are being received? (RxMCastFrames count should increase when your client app sends a multicast packet).

    Steve

  • 0 in reply to Steven Connell
    Intellectual 260 points

    I guess you mean the STATSA and STATSB registers I refer to in my first post? If so, yes I have checked. I haven't been able to isolate just "my own" multicast packages, but I can see that the counters increases continuously which I guess is other multicast packages that existst in our network.

    /OH

  • 0 in reply to OH
    Intellectual 260 points

    We have been working at other stuff for a while, and used a workaround to avoid using multicast, but that's not satisfactory to us.

    Does anyone know if multicast packets are dropped by default using the same setup as the example code in HelloWorld?

    We are currently reusing a lot of that code, and looking into some of the "platform init" code, I see the Pa_create in the res_mgr_init_pass function in resourcemgr.c.

    This led me to scan through the PA API, and i found the Pa_configExceptionRoute function, that in the documentation mentions multicast and silently discarding exception type packets (is multicast that?).

    I have no idea if I am in the right neighbourhood here. Am I at the wrong level looking for the problem? To me it seems like something that could be the problem, but i have not seen this mentioned in any of the other forum threads covering multicast trouble.

    /OH