Showing results for 
Search instead for 
Did you mean: 

STM32H743 general VLAN handling not working as described

Associate II

I am currently implementing a Profinet protocol on the STM32H743 which needs VLAN information in some packet types. Since the VLAN tags are already generated by the software for transmit packets I tried to get these tags passed through the Ethernet MAC. The reference manual (Rev 8, page 2973f) suggest that when setting the VLP flag (Bit 18) a 0 in the VLC would let the VLAN tags pass through the MAC. However, this is not the case. VLC=0, VLC=1 and VLC=3 all cause the deletion of a VLAN tag prepared by the software and these will not be seen on the network. Only VLP=1 & VLC=2 seems to allow the passing of the VLAN Tag, however none of these settings replaces (parts) the prepared VLAN tags as documented for VLP=1 & VLC=2. I could confirm this with the help of Wireshark logs. When VLP=0 all prepared VLAN tags are deleted by the MAC.

For me, the following register settings let pass prepared VLAN tags through the MAC:

  • MACVTR=0x04000000
  • MACVIR=0x006000000
  • MAVIVIR=0x007000000

This should be investigated by the STM32H7 support crew and probably end up in the errata sheet.

I am aware that other software developpers use the transmit descriptor ring VLAN handling capabilities together with the VLTI bit 20 in MACVIR in order to solve the VLAN handling problem. However, the resulting software solution looks rather cumbersome as compared to the generation of the VLAN tags by the protocol software during the paket generation. When I look at the software using the transmit descriptors for VLAN handling I get the idea that there are further errata in this area to be investigated and document.

Associate II

I am so sorry, but the description of the faulty VLAN handling in the STM32H7 / STM32H743 is not correct. In fact the VLAN handling seems to work as described in the reference manual.

The problem is that most of the new Windows PCs silently drop at least one VLAN flag in an Ethernet packet before any monitoring program such as Wireshark is able to access them. So, Wireshark does not really display the "raw" Ethernet packets. Even when switching off the "Priority and VLAN" option in the Windows network configuration almost all network devices (not necessarily Windows) skip VLAN flags. It took me and other specialists about two days to get to the bottom of this and to get a very old Windows 2000 Laptop with an old Wireshark version up an running, which finally shows what is really going on bit-wise.

My firm recommendation to all developers who work with VLAN tags: Get a professional network analyser and do not trust a Wireshark/Windows solution. The Wireshark developers know about this problem and have documented it - it's not their fault.

Pavel A.

Wireshark on Windows has knows issues (for details, visit Microsoft forums).  Use Linux, stay out of trouble.