STM32F746 + Lwip, MCU load due to broadcast ???

[hochul yoo]

Posted on May 02, 2018 at 11:03

Due to the wrong network configuration, 

It is assumed that broadcast packet looping has occurred.

STM32 MCU continuously receives broadcast packets.

As a result, the MCU load increases.

Tested on the STM32F746G-DISCOVERY board,

MCU load increased to 70 ~ 80%.

In this case, the polling period is broken and

Our products do not work properly.

Except for using the Serial to Ethernet Controller with TCP / IP Protocol stack,

Is there a way to avoid this problem?

[AvaTar]

Posted on May 02, 2018 at 11:35

According to my experience, this is a shortcoming of all MCU-based 'IoT' solutions.

That includes not only Cortex M, but all other equivalent microcontrollers.

They just have not the performance to keep up with significant network load.

PC-based applications and Cortex A devices use external or internal PHYs with large packet buffers to decrease load.

IMHO the 'IoT' thing is a joke and a marketing bubble.

[Bogdan Golab]

Posted on May 02, 2018 at 12:18

Capture some Wireshark sniffs to see the structure of the broadcast packets (is this only arp request?).

The aim is to investigate the source of the broadcast and its rationale (too big broadcast domain = vlan, or other problem). I do not want to say that we will fix the problem but I think it is worth to know what is going on in the network.

[AvaTar]

Posted on May 02, 2018 at 12:48

The aim is to investigate the source of the broadcast and its rationale (too big broadcast domain = vlan, or other problem).

A remedy would then be to isolate most of the network traffic from the IoT module(s), to avoid overflowing then.

Pretty sure that becomes much more expensive than replacing the Cortex M module with a Cortex A, Intel Galileo or whatnot ...

[Bogdan Golab]

Posted on May 02, 2018 at 13:46

It may happen that some hosts simply do not respond to arp in this vlan segment and the extra arp load is seen. There might be other reasons not directly related to the broadcast domain size (i.e. vlan size in terms of number of hosts). Just suggested sniffing to learn more about the traffic.

VLAN re-segmentation is of course expensive as it requires IP re-adrressing (not always as easy as DHCP re-configuration). Maybe IoT devices should be located in the separate VLAN. Who knows - we do not know neither the network design nor traffic patterns.

Have no experience how big broadcast load is acceptable by the MCUs.