AM2634: Miscellaneous interrupt in Ethernet AM2634

Hello Srinivas,

I have assigned this thread to the correct owner. Due to timing and the weekend, please expect an initial response sometime early next week.

Best Regards,

Zackary Fleenor

Hello Ti Team,

We are still waiting for your response.

Regards,

Srinivas.

Hi Srinivas, 

To know what is triggering the MISC interrupt, 

First read this interrupt to know which MISC interrupts are enabled:

Then, check which MISC interrupt type event bit:

Miscellaneous level interrupt is used for events such as Link status change, ECC error conditions, configuration changes, ALE events etc.

TEMC said:

Can you provide related documentation for miscellaneous interrupt, CPDMA and CPPI 3.0.

Can you let me know what exactly do you want to know about these

Regards,
Shaunak

Dear Shaunak,

We are encountering MISC Host interrupt. 

Regards,
Srinivas

Hi Srinivas,

If you encounter the MISC interrupt frequent, it might very well be the STATS Update interrupt, it can also be HOST error interrupts.

You can refer the REGISTER ADDENDUM for CPSW and see the CPDMA registers.

In the MCU+ SDK you can refer the enet_cpdma.c file (mcu_plus_sdk/source/networking/enet/core/src/dma/cpdma)

A few questions,

1. Does your application work as expected? By default the MISC interrupts are enabled. I don't think this might be breaking the execution or application flow. If it does, can you share some details about the application and failure

2. If you have a working application and do not need features such as LINK interrupts, STATs interrupts etc, you can also disabled the MISC interrupt. All the CPDMA interrupts are configured/enabled in the EnetCpdma_open() function.

Regards,
Shaunak

Hi shaunak, 

The misc interrupt we are getting is Host error interrupt. And This interrupt is being asserted continously and application is getting stuck at this point as a loop.

And we are unable to find the related info regarding the root cause that will trigger the Host error interrupt in TRM and Register Addendum. It will be of a great help if you can share us related resource

Regards,
Srinivas

Hi Srinivas,

Can you please let me know who your TI FAE/Sales contact is, so that I can share the NDA documents (if appropriate NDA exists). I would be unable to share information beyond Public TRM and Register addendum on Public E2E forum. I can help share the information through the FAE/Lead point of contact

Regards,
Shaunak

Hi Shaunak, 

Thanks for the reply, we will post the details shortly.

Regards,
Srinivas

Hi Shaunak,

Our FAE is Prayag Sahoo, we have already signed NDA with TI. You can check with him.

Hi Srinivas,

Apologies for slow movement here. I had a discussion with Prayag and I can share the details over email

I still have a few questions:

1. At what point in your application do you run into constant Host MISC interrupts which are being asserted? Is this after PHY Alive and MAC Port link up

2. Is it some custom application or some SDK out-of-box example you are using. I would once like to review your configurations. Can you please share your application which I can test/review locally?

3. Does this custom hardware use TI PHY? Is it the same as the on board PHY on AM263x? Do you see a PHY Alive log and MAC Port-link up?

Regards,
Shaunak

Hi shaunak, 

1. We are running into constant Host MISC interrupt after PHY Alive and MAC link UP, to be more specific we are encountering it if we are transmitting based on link i.e., both ports link is UP, suddenly we disconnect 1 cable, still running fine. The interrupt is asserted the moment we plug in the cable. 

2. The application we are using is Custom made, derivative of SDK (implemented as bare metal).

3. Our custom hardware has KSZ804FL Phy (Fiber PHY supporting upto 100Mbps, we are using 100-FX mode in it). Yes, we are able to detect events of PHY link up and down. The transmission and reception is also fine if left undisturbed.

Regards,
Srinivas

Hi TEMC,

If everything works fine unless you disconnect-reconnect the ETHERNET cable, this might indicate something to do with the PHY Link detection. In your application are you reading the PHY status through the MDIO?

Generally MISC interrupts will be used only for STATS, CPTS and MDIO, and if we encounter it only during the PHY UP/DOWN (disconnect/re-connect), it indicates that this issue has something to do with the way we read the PHY status.

One question I have is,

When disconnected and re-connected, does the PHY Alive log ever come up? DO we ever re-connect? Or do we just keep reading the status through MDIO of PHY Alive and that raises the interrupt continuously.

I did check internally and apart from register addendum (which is available public ally), there isn't much that can help with MISC interrupts.

Regards,
Shaunak

Hi shaunak,

We are reading PHY Link status through MDIO only but we are not doing any handling based on the link Up/Down event.

and when we are considering the link status for transmission we are running into MISC Interrupt, But if we are not considering the link status and continuously transmitting independent of link status, everything seems to be working fine.

Shaunak Deshpande said:

I did check internally and apart from register addendum (which is available public ally), there isn't much that can help with MISC interrupts.

please share whatever sources that are available on MISC Interrupt(Host Error Interrupt).

Regards,
Srinivas

Hi Srinivas,

I've shared some details over email/

Regards,
Shaunak

Hi shaunak,

Q1. Have you modified CPDMA driver APIs?

Ans: Yes, we have implemented our own drivers in bare metal by taking TI CPDMA driver code as reference.

Q2. Is the application flow for checking PHY functionality and CPDMA initialization same as other examples?

Ans: Yes

Regards,
Srinivas

Hi TEMC,

Did the details shared over email help?

TEMC said:

Yes, we have implemented our own drivers in bare metal by taking TI CPDMA driver code as reference.

TI Enet-LLD drivers are baremetal as well. They are no reliant on any RTOS, curious to know what was changed? Was is to reduce some overheads to improve performance? 

Regards,
Shaunak

Shaunak Deshpande said:

Did the details shared over email help?

Yes, the details you shared over mail helped we will check that and see what was causing the error.

Shaunak Deshpande said:

TI Enet-LLD drivers are baremetal as well. They are no reliant on any RTOS, curious to know what was changed? Was is to reduce some overheads to improve performance? 

Yes, everything related to ethernet including Enet-LLD drivers are bare metal, and they are not reliant on any RTOS. It is to improve performance and also to gain more control over everything that is happening with ethernet.

Regards,
Srinivas

TEMC said:

Yes, the details you shared over mail helped we will check that and see what was causing the error.

Thanks

TEMC said:

Yes, everything related to ethernet including Enet-LLD drivers are bare metal, and they are not reliant on any RTOS. It is to improve performance and also to gain more control over everything that is happening with ethernet.

Got it, Thanks for sharing. Maybe once we would like to check the functions which are related to CPDMA and MISC interrupts as well.

Regards,
Shaunak