This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: AM6442 PRU Ethernet receive packet DMA Ring Acc question

Part Number: AM6442

Tool/software:

Introduction to software and hardware environment:
  Hardware: Self-developed board based on am6442
  Operating system: Self-developed RTOS
  PRU driver: uboot ported from Linux SDK 9.0

There will be many broadcast packets when cssg1 port0/port1 is connected to the switch. During the initialization process of the network, I checked the MII_G_RT register and PA_STAT memory information and found that the data was received and transmitted to the packet DMA. Now I am starting to bind the DMA channel and register interrupts, but I have found that interrupts cannot be generated normally.
I would like to know:
1. If there is data in the DMA channel, will it cause the binding channel to interrupt to fail?
2. When should ICSSG1 Prueth bind the dam channel to interrupt?

  • Hi,

    1. If there is data in the DMA channel, will it cause the binding channel to interrupt to fail?
    2. When should ICSSG1 Prueth bind the dam channel to interrupt?

    We suggest to pair the channel to interrupt even before letting the packets to enter into the switch. Ideally, we would configure the hardware, and once we are ready to handle the network, we would update the port state to handle the traffic. Is there any requirement for you that you had to allow the packets even before completely initializing the hardware? Please let us know so that we can better understand the requirement, and suggest possible solutions

    If followed the above sequence, there wouldn't be any packets in the DMA while binding the interrupts. We haven't tried binding when there are packets explicitly waiting in the DMA. I can run that test if needed to understand the expected behavior. But since I am currently on another commitment, I would be able to provide an update end of next week.

    Regards,
    Teja.

  • Hi,Teja Rowthu

    Our prueth driver code was ported from uboot, but the interrupt initialization part was ported from Linux. According to your suggestion "Ideally, we would configure the hardware, and once we are ready to handle the network, we would update the port state to handle the traffic", I resolved the issue by setting the port state after the hardware initialization was completed.