AM6442: Interrupt Pacing is not working in ICSS-EMAC for AM64x

Hi Upender,

Could you please explain the issue you are seeing? Are you seeing issues with startup?

The rx opeerations are not being handled through interrupt mechanism provided in icss_emac.c: ICSS_EMAC_rxInterruptHandler function.

Are you not seeing packet hitting in the ISR?

Regards,
Prajith

Hi Prajith,

No. Rx ISR is not hitting. RxTask is in wait state because RxInterruptHandler never posts Semaphore.

But Link ISR works fine.

NRT traffic is going directly to ICSS_EMAC_rxPktGet, not through Rx Task. This is causing interruptions to the MainTask which is doing the Profinet Stack init.

Where is PRU Interrupt to ARM Interrupt mapping done?

Where RT and NRT callbacks in ICSS Params configured?

Thank you.

Best Regards,

Upendar

Hi Upender,

The mapping of interrupt is done in the icss emac init (done insie stack now) - The mapping file can be found here - source\industrial_comms\profinet_device\icss_fwhal

I expect the interrupt to be hitting for packet reception. I will check this and comeback.

Regards,
Prajith

Hi Prajith,

What is the mapping file name?

And a quick response would be great. I am stuck with my evaluation.

Please take this as high priority.

Thank you.

Best Regards,
Upendar

Hi Upender,

Could you clarify the SDK version you are using?

Regards,
Prajith

Hi Prajith,

SDK 8.6. with Profinet Stack. I tried also with an intermediate release with SDK 9.1 which I got last month. But the behaviour is same.

I am waiting for Profinet Full Stack release with SDK 9.2.

Regards,
Upendar

Hi Upender,

Apologies for the delay in response.

Upendar Sama said:

What is the mapping file name?

The mapping file name is "tiswitch_pruss_intc_mapping.h", located in the folder "{ICSDK_09.01_folder}\source\industrial_comms\profinet_device\icss_fwhal".

We will be checking this behavior on our test setup and will update you on the result by tomorrow.

We are suspecting some issues to pop up on GP EVM's. Meanwhile, would it be possible for you to try this application on AM64x HSFS EVM?

Best Regards,
Laxman

Hi Laxman,

I don't have SDK 9.1 with Profinet Stack. I just got the libraries from TI via email.

We are using HSFS device. our device part number TMDS64EVM.

Looks like SDK 9.2 with Profinet Stack will be released this week. I want to try again with the new stack. But if you know have access to SDK 9,2 stack, please test with the new stack.

Thank you.

Best Regards,
Upendar

Hi Upendar,

The mapping file should be the same irrespective of SDK version.

We will be testing this with SDK 9.2 and get back to you on the results by mid of next week.

Best Regards,
Laxman

Hi Laxman,

Thank you. TI supposed to release the SDK 9.2 by today. But still there has not been any information on this. 

Do you know if the  release status of SDK 9.2 with Profinet stack?

Best Regards,
Upendar

Hi Upendar,

For this release also, the SDK9.2 with Profinet stack will be shared via mysecure link. This will be released by next week.

Best Regards,
Laxman

Hi Laxman,

I have recieved the latest Profinet Stack and the behaviour with RxHandler is same. Still. ICSS_EMAC_rxInterruptHandler is not being triggered.

I am using the sample profinet demo application provided with the release.

Have you done any tests?

Could you please share your findings?

And I have tried modifying the multicast filter table and use that firmware. But the build is at linker stage with code given under C:\ti\ind_comms_sdk_am64x_09_02_00_09\source\industrial_comms\profinet_device\icss_fwhal

Errors: g_SyncCtrlFup and g_SyncCtrlPort are undefined symbols used in PN Stack.

Thanks you.

Best Regards,
Upendar

Hi Upender,

Thank you for your patience. We have performed certain tests and have observed that the Rx ISR is indeed not hitting. We have identified the cause of this issue and actively working on this. We will get back to you on any progress made here.

Upendar Sama said:

And I have tried modifying the multicast filter table and use that firmware. But the build is at linker stage with code given under C:\ti\ind_comms_sdk_am64x_09_02_00_09\source\industrial_comms\profinet_device\icss_fwhal

Errors: g_SyncCtrlFup and g_SyncCtrlPort are undefined symbols used in PN Stack.

Currently we are using a patched library for the PROFINET Application and hence it would not be possible to rebuild the PROFINET FWHAL and test. 

Best Regards,
Laxman

Hi Upender,

We have found the reason for "ICSS_EMAC_rxInterruptHandler" not hitting.
In the current implementation, when the device receives a frame, the PRU FW raises a receive interrupt which is serviced by the Rx ISR. This Rx ISR is initially configured to "ICSS_EMAC_rxInterruptHandler", but certain changes are made in the stack which updates the Rx ISR to be used to another API which is present in the stack. 
In conclusion, the receive operations are being handled through interrupt mechanism here but the Rx ISR is used from the stack.

We will be having an internal discussion to evaluate the next steps required to tackle this issue which is causing an increase in the startup time. We will also perform some tests on our side to optimize the startup time.   

Meanwhile, could you please explain what is your use case here and what effect this delay has on your application?

Best Regards,
Laxman

Hi Laxman,

Thank you for the response.

I have a question. Why does PN Stack handing NRT traffic? My understanding is that RT traffic goes to PN Stack and NRT goes to lwip stack.

My usecase is to get the startup time as short as possible. And my observation is that NRT traffic (I think multicast traffic from PLC) is causing the delay in PN Stack init. I could see NRT callback while PN Stack Init is going on.(This observation from Old stack SDK 8.6). 

With the new stack performance certainly improved. But RX ISR behaviour has not changed. And one more thing, because of this RxISRhandler not being called, RX Task in ICSS-EMAC is in perpetual wait state. And I have also observed there is not much effect because of ICSS-EMAC configuration items like priority, interrupt pacing, RT-NRT Queues etc.

For now, we are not concentrating on PN Evaluation but this is important for us. If you can provide some solution within next few weeks, it would be great. Or atleast finalize your design and document it. Current stack documentation and design are not matching.

And It should be possible to change FWHAL also but that does not work to filter out multicase message during startup. We would like to use these features to speed up the startup.

Thanks again.

Best Regards,

Upendar

Hi Upendar,

Upendar Sama said:

I have a question. Why does PN Stack handing NRT traffic? My understanding is that RT traffic goes to PN Stack and NRT goes to lwip stack.

In the current design, the stack is responsible for all the incoming and outgoing packages (i.e RT and NRT). That means the low level interface from LWIP is served by the PN stack. This is required to pass the Netload test. Also not all the NRT traffic goes to stack. There are some frames like LLDP and DCP which needs to be processed within the stack.

Regarding the startup time, we would be working on this and would require some time to cleanly implement the changes to optimize the startup time. We will get back to you with an update on the progress made on this issue within two weeks.

Thank you for your patience,
Laxman 

Hi Laxman,

Thank you for the response. 

We will wait for your update.

Best Regards,
Upendar

Hi Laxman,

Is there any update?

Thank you.

Best Regards,
Upendar

Hi Upendar,

We would need to check this in detail as to how we can cleanly port the interrupt handling from stack to ICSS-EMAC. This would take some more time as we are currently working on some release activities. But until then we are planning to test a workaround which might resolve this issue. We will get back to you mid next week to confirm this.

Best Regards,
Laxman