2388184_en-US

Yes

host-to-switch trailer not removed on SJA1110

I am sending ethernet frames via the host processor (Cortex-M7) on a SJA1110. To route them to the specific ports on the switch I am using the host-to-switch header/trailer described in UM11107 under 5.8.2.
The frames are received on the correct port however the trailer is not stripped or only partily stripped. For reference here is the same frame once before sending stored in the txBuffer and once after receiving in the rxBuffer of another device:

01 80 c2 00 00 10 68 58 c5 00 11 02 8b 8c 88 39 88 b7 5a 46 00 01 02 06 68 58 c5 00 11 02 04 01 00 06 01 02 12 01 01 14 0e 01 02 11 00 c5 58 68 08 d8 26 c0 cb fd 18 00 00 00 00 ---- 00 04 00 00 00
======                                                                                                                                                                                                                                     
01 80 C2 00 00 10 68 58 C5 00 11 02             88 B7 5A 46 00 01 02 06 68 58 C5 00 11 02 04 01 00 06 01 02 12 01 01 14 0E 01 02 11 00 C5 58 68 08 D8 26 C0 CB FD 18 00 00 00 00 ---- 00 04 00 00 00

As you can see the header is removed completly but the trailer (everything after the 4 dashed lines) is not removed (or set to all 0s because atleast 64 bytes are required for the ethernet frame to be valid).

Re: host-to-switch trailer not removed on SJA1110

Hello @flxwly ,

From the provided data, the host-to-switch header seems to be recognized by the switch, because the 4-byte header is removed from the outgoing frame. However, the trailer bytes still appear at the end of the received frame.

One important point to check is the TRAILER_POS field in the host-to-switch header. The header bytes in your example are 8b 8c 88 39

Interpreting this according to the host-to-switch header format gives HEADER_TYPE = 0x8B8C, HOST_SWITCH = 1, TRAILER = 1, and TRAILER_POS = 57. However, in the transmitted frame shown in your dump, the 5-byte trailer appears to start at byte offset 59 from the MAC DA field, zero-based. Depending on the exact position counting convention relative to SFD, the expected value may differ by one, but the encoded value 57 does not seem to match the actual trailer position.

Therefore, please first check how the TRAILER_POS field is calculated and try setting it to the position corresponding to the actual first byte of the trailer.

There is also a second point: the provided test frame is very short. If the 5-byte trailer were stripped, the resulting Ethernet frame would become shorter than the minimum Ethernet frame size without FCS, so padding would need to be added again on egress. To avoid this ambiguity, could you please repeat the test with a longer payload, for example by adding 16 or 32 dummy bytes before the host trailer? This will make it clear whether the trailer is really stripped or not.

Please also confirm that the egress port where the second device receives the frame is configured as a normal port. According to the UM, the header and trailer are stripped when the frame egresses a normal port, while the control information is preserved when the frame egresses the host port or a cascaded port.

Finally, could you please share how the 5-byte trailer value `00 04 00 00 00` is generated? It would be useful to verify the bit packing of FRAMEID, PRIO, SWITCHID, and DESTPORTS against the format shown in the user manual.

Best regards,

Pavel