AM3359: Profinet Slave multicasts

Manuel,

As described in the ICSS_EMAC switch firmware document (pdk_am335x_1_0_12\packages\ti\drv\icss_emac\firmware\icss_switch\docs):

Multicast Frame:
If a frame is multicast then a receive table is looked up using the destination address to determine whether the frame is received or not. Similarly, a look up also happens in the forward table to determine whether it is forwarded or not. If the destination address doesn’t fall in the defined group of multicast addresses then it is received and forwarded like a broadcast frame.

Also the storm prevention description should help minimize 'the load on the processor' as the credit is configured by the host.

4.1.13 Storm Prevention
Storm prevention is primarily done on PRU’s using a credit based scheme. It is
explained below.
 The Host (Cortex A8) writes the number of Multicast+Broadcast packets allowed in a 100ms interval in DRAM of PRU. (STORM_PREVENTION_OFFSET)
 This value (credits) can be configured using the API setCreditValue()
 As soon as the PRU encounters a Multicast/Broadcast packet it decrements the value written in memory by 1 and allows the packet to pass through. If the value goes to 0 the packet is dropped
 At the end of every 100ms interval Cortex A8 writes the value once again. Function resetStormPreventionCounter() in file icss_StormControl.c

Regards,
Garrett

Thanks, I knew that already. The documentation is for the multicast in the switch firmware, not the profinet. The Multicast filter works differently there and I see no reason why it (profinet pru firmware) should leave other multicasts through to the cpu (which it does). Maybe it could simply just forward them? Or what is the idea behind that? Of what use could these frames possibly be in a profinet environment?

In the Profinet Demo firmware from TI, the storm prevention is used differently, because 100ms would be too slow, you would loose connection.

Instead the task receiving the frames has very low priority and basically resets the counter to 2000 every time after it receives frames.

If you look at NIMU_ICSS_pktPoll, it says "This function is called at least every 100ms, faster in a polling environment. The fTimerTick flag is set only when called on a 100ms event.".

But I checked by polling the storm prevention counter in the pru firmware. When there is no ethernet traffic, it resets the counter every few us, basically as fast as possible. When there is a real packet storm, if the task does not get to run (as it has low prio) the storm prevention automatically kicks in so it kind of self regulates. That what I gathered from the firmware, not the documentation. Correct me if I am wrong. My guess is that if fTimerTick would really be set only every 100ms, the device would fail the conformance test.

After all I don't want to rely too much on the storm prevention, especially when simple filtering could do the trick much better. As the storm prevention cuts all traffic (not quite all in profinet firmware I think but there is no documentation), it should only be the last resort to keep the firmware somewhat running.

Best regards,

Manuel

Manuel,

You are right - The documentation is for the multicast in the switch firmware, not the profinet.

I was trying to show the high level concept of multicast filter and storm control in Profinet which is similar as described in the icss emac switch document.

I will be out of office for two weeks, but my colleague will help find out the design background and then get back to you...

Regards,
Garrett