AM3356: CPM ISR miss when the IRT and RT mixed

Hi Andy,

Thank you for creating a new thread.

We have performed a basic test to check whether the number of CPM's received by FW matches the number of PN_cpmIsrHandler ISR calls and it is currently matching. It seems like there might be some differences in our setup. Could you answer the following questions to ensure that our configuration in TIA portal and driver match?

1) Are you currently using the TMDSICE3359 board?

2) What is the send clock set in PLC and the update time for the IRT device in TIA portal?

3) Have you enabled Isochronous mode in the PLC? If yes, what are the parameter values configured here?

4) What are the "value" and "duration" parameters passed to "PN_ISO_initGPIOEvent" API? 

Best Regards,

Laxman

1)I tested on my board.Refer to the ICEv2 design.

2)send clock is 2ms.

3)Yes, enable the Isochronous mode 

4)To_IsoMHandle=PN_ISO_initGPIOEvent(appPnHandle,PNISO_MODE_GPIO,to_ns,20000); 
   Ti_IsoMHandle=PN_ISO_initGPIOEvent(appPnHandle,PNISO_MODE_INTERRUPT,ti_delay_ns,20000);

Hello Andy,

Thank you for your response, will test out with these settings once. Will provide an update on this issue by next week.

Best Regards,
Laxman

Hi Andy,

After adjusting the send clock parameter and ISOM parameters values, we still are not observing any misses in CPM ISR after performing a long test run for 12 hrs.  We will be requiring some assistance from TMG to solve this problem. We will get back to you within 2 weeks on any progress made on this issue.

Meanwhile, could you let us know how often are you observing the error and is it consistent or sporadic?

Best Regards,
Laxman

Hi Andy,

Hope you are doing well. 

We would like to understand the nature of this issue. Could you please let us know how often you are observing this error and whether it is consistent or sporadic?

Best Regards,
Laxman

Hi Laxman

Now I tested for long time.But not make it fail again.

Best Regards,

Andy Zhou

Hi Laxman,

There are some error frames in IRT and RT mixed.

Hardware configuration is the same. I tested for 35 minutes.

PLC--IRT--RT

PLC--IRT--IRT

It was not an accident. I tested it many times.

PLC+IRT+RT: error frames

PLC+IRT+IRT： no error frame

I used the Hischer netANALYZER to capture data.

Best Regards,

Andy Zhou

Hi Andy,

Couple of queries here,

1) Could you share the wireshark capture files here? Have you checked what are these "short frames" and MII_RX_ERR frames?

2) Do these errors have any effect on your application or does it cause any failures?

Best Regards,
Laxman

Hi Andy,

Thank you for your reply. Glad to hear that you are facing no issues on your project. Please let us know if you face any further issues.

Best Regards,
Laxman

Hi Laxman

The last IRT is always error. I do some test.

I only tested case 1 in weeks ago. So I did not find any problem.

This is packets captured by wireshark.You can filter by "pn_rt.frame_id == 0x100 &&pn_rt.ds!=0x35"

IRT1RT4-CommLoss2.zip

I think the last IRT transimit many RT frames which caused the error.

I tested it many times and the error occurred within 30 minutes. you need 2 or above RT devices.

Looking forward to your reply!

Andy Zhou

Hi Andy,

We will test with this setup on our side and get back to you.

Best Regards,
Laxman 

Hi Laxman,

Did you get the results of your test ?

Version info:

processor_sdk_rtos_am335x_6_03_00_106

PRU-ICSS-Profinet_Slave_01.00.05.00

TMG: PNIO-D-Stack-V5_8_0_0_with_TI_V01_00_05_00

Looking forward to your reply!

Best Regards,

Andy

Hi Andy,

Apologies for the delay. I checked the logs where the errors occurred and it looks like the data status and cycle counter data is present in the packet but the checksum is missing due to shorter size of the frame. It seems like the packet is truncated here.

On our side, we have performed tests with PLC, 1 IRT device and 2 RT devices connected in daisy chain network and ran the test for 30 mins. Here we were able to notice around 5 frames that were truncated. We are currently investigating the cause of this issue, and will get back to you within a week.

Best Regards,
Laxman

Hi Laxman,

Is there any progress？

Best Regards,

Andy

Hi Andy,

Apologies for the delay. We had been occupied with some release activities due to which there has been slight delay in debug here. We are currently suspecting this issue to be caused due to Tx FIFO delay calculations in the FW which will lead to truncation of the frames. We will get back to you by the end of next week with any updates on this issue.

Thank you for your patience.
Laxman

Hi Laxman,

Is there any progress？It`s been almost 3 weeks.

Best Regards,

Andy

Hi Laxman,

I have been waiting for your reply.

Best Regards,

Andy

Hi Andy,

Apologies for the delay. We had been suspecting the FIFO delay calculations to cause the issue here and it seems like this is a partial cause of the issue. Due to some timing related issue the whole PPM packet is not being sent by the device, and it is always the CRC of the frame that is getting truncated. We are still looking into the possible solutions for this issue and have been trying to implement a fix and test it. We will get back to you with the result of this test soon.

Thank you for your patience,
Laxman