• State
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 42 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM6422: AM6422 SDK11.2 CPSW SWITCH SPINLOCK

Wendy
Intellectual 920 points

Part Number: AM6422

Hello,

    We are developing on the AM6422 platform using the R5F1-0 core, and we are using the CPSW Ethernet module in switch mode. When received Ethernet data is identified as a GOOSE packet, it is written to shared memory. We use a hardware spinlock for synchronization during this write operation.

    Our system consists of 12 terminals connected in a cascade topology. In our current simulation experiment, we connected the Ethernet ports of the head and tail terminals to the same external switch, which creates a physical network loop and causes a network storm.

    Consequently, the GOOSE packets continuously accumulate on the network, and the terminals receive an exponentially increasing number of GOOSE packets, leading to highly frequent writes to the shared memory. After running for about 10 minutes, tracing revealed that acquiring the spinlock fails. Due to the strict real-time requirements of GOOSE data, we must use a busy-wait (spin-wait) mechanism when waiting for the lock. As a result, even after the storm stops, the Ethernet receive task remains stuck waiting for the lock in the shared memory write function, causing the Ethernet subsystem to become unresponsive.

    We have monitored the lock and unlock counters, and they are perfectly consistent. There is no lock leakage (e.g., a lock being acquired without being released). We would like to know if there are any issues with our lock operations, and we kindly request your suggestions. Additionally, how should we handle or mitigate this network storm scenario?Our lock operation code is attached below.

static void sharemem_lock(uint32_t lockNum)
{
    int32_t  status;
    uint32_t retry = 0;
    /* Spin till lock is acquired */
    while(1U)
    {
        status = Spinlock_lock(spinlockBaseAddr, lockNum);
        if(status == SPINLOCK_LOCK_STATUS_FREE)
        {
            break;  /* Free and taken */
        }
    }}

  • 0
    TI__Genius 10810 points

    Hi,

    To prevent high traffic network loops, one should add ALE entries to prevent switching the packets with source address of the packet being same as the current device. In the example applications provided in the SDK, this ALE entry is not added as it assumes the topology to be not forming a loop. For loop topology, please add an ALE entry rejecting the packets to both MACPORTs as well as HOSTPORT to prevent flooding. You can do it with the help of "CPSW_ALE_IOCTL_ADD_MCAST" IOCTL.

    Regarding the spinlock, it depends on how your application is handling the lock and unlock, along with the critical sections. The provided info is not enough to completely assess the behaviour. I will check with the experts to find out what additional information is needed to analyse the spinlock behaviour. Please share the method used for verifying the lock leakage as well. 

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Intellectual 920 points

    Hello，

        Regarding the CPSW_ALE_IOCTL_ADD_MCAST you mentioned, we are currently using it. We have configured it to only receive subscribed GOOSE packets. In fact, we cannot receive the packets sent by ourselves. However, when a physical network loop occurs, it is the GOOSE data sent by other terminals that is continuously looping and being received by this terminal. It seems this approach cannot solve this specific scenario.

        Regarding the spinlock, we acquire the lock within a task, write data to the shared memory, and then release the lock. We are actually using 2 different locks, each managed in 2 different tasks. When monitoring, we count the lock and unlock operations for each respective lock, and the results are consistent. However, due to the large volume of network data, we frequently operate on the shared memory, which means the locks are also locked and unlocked very frequently.
        Will this high-frequency operation affect the hardware state of the lock? In my understanding, since the lock IDs are different, their lock/unlock operations should not affect each other.

        The code I provided previously represents our current implementation: we busy-wait for the lock without any timeout. Our requirement is that we must wait for the lock and write the data into the shared memory; otherwise, it will affect our core functionality (we cannot drop GOOSE packets).

        I have another question: Do we need to enter a critical section when using the lock? That is, should we call the taskENTER_CRITICAL() function to prevent task preemption during the lock acquisition and release process?

  • 0 in reply to Wendy
    TI__Genius 10810 points

    Hi,

    Can you please confirm if the packet switching between the ports is also restricted when the packets of SRC MAC address being same as Host mac Address? Without this, the storm/flood prevention will not be in action, and only the host of corresponding packet will stop receiving the packets.

    Regarding the spinlock, I will share the thread with our expert and will get back to you.

    Thanks and regards,
    Teja.