MCU-PLUS-SDK-AM243X: ICSSG Switch – Unexpected Loop When Switching One Port to FORWARD State

Rémi Moessner

Prodigy 40 points

Part Number: MCU-PLUS-SDK-AM243X

Tool/software:

Hello,

I am running tests with a custom project based on enet-layer2-icssg example on the AM243x EVM (MCU+ SDK).

Setup:

Setting port to BLOCKING dor test 1 and one BLOCKING the other FORWARD for test 2
Both ICSSG ports are connected to the same external switch (network loop scenario).

Test 1 – Both Ports BLOCKED:
I set both ports to ICSSG_PORT_STATE_BLOCKING.
As expected, no network loop is observed.

Test 2 – One Port FORWARD, One Port BLOCKED:
I then change one of the two ports to ICSSG_PORT_STATE_FORWARD.
At this point, I get a network loop.
This is not the expected behavior, as only one port should be forwarding traffic, and the other is supposed to remain blocking.

Analysis:
I compared the R30 messages sent to the PRU under Linux vs. MCU+ SDK:

Linux (kernel driver):

static const struct icssg_r30_cmd emac_r32_bitmask[] = {
    {{0xffff0004, 0xffff0100, 0xffff0004, EMAC_NONE}}, /* EMAC_PORT_DISABLE */
    {{0xfffb0040, 0xfeff0200, 0xfeff0200, EMAC_NONE}}, /* EMAC_PORT_BLOCK */
    {{0xffbb0000, 0xfcff0000, 0xdcfb0000, EMAC_NONE}}, /* EMAC_PORT_FORWARD */
};

MCU+ SDK:

[ICSSG_UTILS_R30_CMD_DISABLE] = {
    { 0xffff0004, 0xffff0100, 0xffff0104, ICSSG_UTILS_CMD_NONE }
},
[ICSSG_UTILS_R30_CMD_BLOCK] = {
    { 0xfffb0040, 0xfeff0200, 0xfffb0008, 0xffff0200 }
},
[ICSSG_UTILS_R30_CMD_FORWARD] = {
    { 0xffbb0000, 0xfcff0000, 0xdcf30000, ICSSG_UTILS_CMD_NONE }
},

I noticed that the bitmasks are different between Linux and MCU+ SDK. If I apply bitmask from linux to mcu sdk, the result is not better

Then I tried to manually tweak the MCU+ SDK values and the best results came with the following values:

[ICSSG_UTILS_R30_CMD_BLOCK] = {
    { 0xfffb0040, 0xfeff0200, 0xfffb0008, 0xfeff0200 }
},
[ICSSG_UTILS_R30_CMD_FORWARD] = {
    { 0xffbb0000, 0xfcff0000, 0xdff30000, 0xFCFF0000 }
},

This improves the situation, but the result is still not fully correct : sometimes, if i set both ports in forward, packets are not forwarded correctly.

Questions:

Are the RXPRU/TXPRU/RTU firmwares the same between Linux and MCU+ SDK?
Are my tests makes sense to test the BLOCKING and FORWARDING packets ? Note : I am able to send special packet in BLOCKING mode !
Are the R30 bitmasks correct ?

Thanks in advance for your help!

7 days ago

0 Rémi Moessner 6 days ago

Prodigy 40 points

Hello,

I think the remaining issue with my updated bitmasks were on ICSSG_UTILS_R30_CMD_DISABLE. Indeed it was not using RTU_REM.

Please find my latest "fix" on icssg_utils.c :

[ICSSG_UTILS_R30_CMD_DISABLE] =
{
    { 0xffff0004, 0xffff0100, 0xffff0004, 0xffff0100 }
},
[ICSSG_UTILS_R30_CMD_BLOCK] = {
    { 0xfffb0040, 0xfeff0200, 0xfffb0008, 0xfeff0200 }
},
[ICSSG_UTILS_R30_CMD_FORWARD] = {
    { 0xffbb0000, 0xfcff0000, 0xdff30000, 0xFCFF0000 }
},

Is that fix makes sense ? Or does the inital bitmasks should work ?

Thanks

Rémi

0 Jayachandran Rameshbabu 6 days ago in reply to Rémi Moessner

TI__Expert 5884 points

Hi Remi,

Rémi Moessner said:
Are my tests makes sense to test the BLOCKING and FORWARDING packets ? Note : I am able to send special packet in BLOCKING mode !

In blocking port state, only special packets are permitted to be transmitted and received. For ex: special packets include Peer Delay Messages (used for time synchronization) and Bridge Protocol Data Unit (BPDU) packets (used for Spanning Tree Protocol). During a switching loop scenario, nodes continue to exchange these special packets even when ports are in blocking state, as they are essential for network topology management and timing synchronization.

What is your use case?

Which Linux SDK and RTOS SDK version bit mask are you comparing? I need to double check the bit mask

BR
JC

0 Rémi Moessner 5 days ago

Prodigy 40 points

Hi Jayachandran,

Jayachandran Rameshbabu said:
In blocking port state, only special packets are permitted to be transmitted and received. For ex: special packets include Peer Delay Messages (used for time synchronization) and Bridge Protocol Data Unit (BPDU) packets (used for Spanning Tree Protocol). During a switching loop scenario, nodes continue to exchange these special packets even when ports are in blocking state, as they are essential for network topology management and timing synchronization.

It is also my understanding, that is why I expect if one port is BLOCKING and the other is FORWARD, with both ports connected on a standard switch to not have a "loop" when i send a broadcast on the network.

I'm able to send SPECIAL packets (packets identified in FDB as special) on blocking port : that is OK.

My issue is really that if I forward a port, the second port is not BLOCKING anymore and causes a loop. My understanding is that a BLOCKING port should remain BLOCKING if the other port is FORWARD. This is what i get with the fix i wrote.

* Both port BLOCKING : can only send and receive FDB special packets

* One port FORWARD and the other BLOCKING : the blocking port can receive emit / special packet but no other packets

* Both port FORWARD, act as a switch

Jayachandran Rameshbabu said:
Which Linux SDK

ti-processor-sdk-linux-am64xx-evm-09.02.01.10

Jayachandran Rameshbabu said:
RTOS SDK

MCU-PLUS-SDK-AM243X 11_00_00_15

Regards,

Rémi

0 Rémi Moessner 5 days ago

Prodigy 40 points

Hi again,

I checked bitmask on latest processor sdk (11.01.05.03), it is the same ti-processor-sdk-linux-am64xx-evm-09.02.01.10

I checked bitmask on latest mcu plus sdk (11.01.00.17) for am24, it is the same as MCU-PLUS-SDK-AM243X 11_00_00_15

Rémi

0 Jayachandran Rameshbabu 5 days ago in reply to Rémi Moessner

TI__Expert 5884 points

Hi Remi,

09.02 later we had a fix in MCU+ SDK.

Did you try with these changes below? Bit mask changes only on the "block" command.

    [ICSSG_UTILS_R30_CMD_DISABLE] =
    {
        { 0xffff0004, 0xffff0100, 0xffff0104, ICSSG_UTILS_CMD_NONE }
    },

    [ICSSG_UTILS_R30_CMD_BLOCK] =
    {
        { 0xfffb0040, 0xfeff0200, 0xfffb0008, 0xffff0200 }
    },

    [ICSSG_UTILS_R30_CMD_FORWARD] =
    {
        { 0xffbb0000, 0xfcff0000, 0xdcf30000, ICSSG_UTILS_CMD_NONE }
    },

BR,
JC

0 Rémi Moessner 5 days ago

Prodigy 40 points

Hi Jayachandran,

Don't know if it is a misunderstanding on my side, but your BLOCK bitmask

{ 0xfffb0040, 0xfeff0200, 0xfffb0008, 0xffff0200 }

is exactly equal to the BLOCK bitmask of my mcu + sdk i sent in the initial post

{ 0xfffb0040, 0xfeff0200, 0xfffb0008, 0xffff0200 }

Regards,

Rémi

0 Jayachandran Rameshbabu 5 days ago in reply to Rémi Moessner

TI__Expert 5884 points

Hi Remi,

Correction, leave disable untouched and change only "forward" command.

[ICSSG_UTILS_R30_CMD_DISABLE] =
{
{ 0xffff0004, 0xffff0100, 0xffff0104, ICSSG_UTILS_CMD_NONE }
},

[ICSSG_UTILS_R30_CMD_BLOCK] =
{
{ 0xfffb0040, 0xfeff0200, 0xfffb0008, 0xffff0200 }
},

[ICSSG_UTILS_R30_CMD_FORWARD] =
{
{ 0xffbb0000, 0xfcff0000, 0xdcf30000, 0xFCFF0000}
}

BR
JC

0 Rémi Moessner 5 days ago

Prodigy 40 points

Hi,

It looks like strangely to my initial fix proposal (same case and value for FORWARD REM_RTU), but as i said, this fix was not complete (cf. my full proposal with an update of DISABLE on RTU & REM_RTU)

Rémi Moessner said:
Please find my latest "fix" on icssg_utils.c :

Without latest fix, depending on the disabled/forward/blocking order for both ports), i got some times no forward in forward mode.

Regards,

Rémi

Arm-based microcontrollers

Arm-based microcontrollers forum

MCU-PLUS-SDK-AM243X: ICSSG Switch – Unexpected Loop When Switching One Port to FORWARD State