AM3359: DHT tests failing when executing SPIRTA

Adding a bit more context, I used some GPIOs to track some of the interrupts (ppm, cpm, etc) when the issue is reproduced. In the following image, the yellow line shows when the program enters and leaves the PN_cpmIsrHandler, while the blue line shows the same but for the PN_ppmIsrHandler

As you can see, it looks like the ppm isr is getting blocked somehow, but I couldn't find what is blocking it. Apparently, it is not blocked by the code inside the ppm isr function

Hi Luis,

Could you answer few questions to understand the issue in detail:

1) Do you see this issue with the application from the downloaded package? Are using PRU-ICSS-PROFINET-SLAVE v01.00.05.00?

2) Is there any specific SPIRTA test case where the failure is occurring?

Regards,
Laxman

1) Do you see this issue with the application from the downloaded package? 

I haven't tried this yet. But I am working with PRU-ICSS-PROFINET-SLAVE v01.00.05.00

2) There can happen in many tests, but the test were I have reproduce it the most is the DHT test case

Hi Luis,

Kindly let us know if the issue exists with the out of box example, meanwhile the tests we have conducted previously have not revealed the issue with the SPIRTA tool from older test bundle. There is a possibility for update on the test criteria in the recent versions. Could you also mention which test bundle version you are using to run the tests?

Regards,
Laxman

Hi Laxman,

Ok! I will try to reproduce the issue with the initial example. I am working with the Profinet test bundle 2.44.1.

Just to add another note, I have noticed that sometimes the slave never sends cyclic messages after the initial negotiation:

Regards,

Luis

Hi Luis,

Luis Nuñez said:

Just to add another note, I have noticed that sometimes the slave never sends cyclic messages after the initial negotiation:

For IRT communication, there might be a slight delay after initial negotiation and the communication will only start after the "RTClass3_portStatus" is set to "RUN" in the DUT. Are the cyclic frames never sent after the initial connection?

Regards,
Laxman

Hi Laxman,

I checked further the capture and indeed the frames are sent when the port status is changed to RUN, but a few packets later, the port status changes again to OFF and the slave stops sending packets

Later, the slave reports again a port state change to RUN, but it does not send RTC3 frames. Then the DHT/WDT alarm is triggered

These screenshots were taken using the PerformanceIndicatorCheck01 test case.

I am attaching some captures of some failed test cases. The error is apparently the same in all of them

failed_test_cases.zip

Thanks for your help,

Luis

Hi Luis,

Thank you for sharing the logs. The error cases most likely seems to be caused due to update in the test case scenario in the latest test bundle. The latest test bundle is not supported with the PROFINET package v01.00.05.00. However we are currently in the planning phase to update the PROFINET application to support the latest test bundle. We will share more details once the package is updated and ensure these issues are resolved.

Regards,
Laxman

Hi Laxman,

Have you already identified the same issue on your side? Or could you identify a difference between the previous test case and the new one?

Regards,

Luis

Hi Luis,

Thank you for your patience for our test results. I did run the DHT testcase for 5 iterations with the binary from the PROFINET package and have observed alll iterations to be passing. I have currently used the test bundle 2.44.3.

Have you run the test with out of box binary? Also can you share the binary which you have used to run the test?

Regards,
Laxman

Hi Laxman,

I'm sorry. I haven't been able to test the out-of-the-box binary, but I am almost certain that it will not show the bug, or if it does, it will be after many iterations of the test.

I have tested previous revisions of our firmware and I found one revision in which the test only failed 3 times in about 37 iterations, so I think further changes only make the issue most likely to happen, but at the same time I am not sure where it was initially introduced.

I can share the binary. Could I share it to you privately? I can also send the .cfg file so you can see the differences if it is useful. Also, the issue seems to be more frequent in the release build, compared to the debug build.

In the meantime, I would like to focus on what might be blocking the PPM interrupts (see the screenshot I sent in the second message), I have tried to use GPIOS to identify in the oscilloscope what other Hwi might block the isr handler, but I haven't found it. Do you know a way to investigate that more effectively?

Thanks for your help,
Luis

Hi Luis,

Looking at the oscilloscope display, most likely the issue seems to be caused due to an interrupt of higher priority blocking the CPM and PPM ISR. We will review the interrupt priorities and provide an update.

Meanwhile, I will send a mail now and you can share the required files for debug.

Regards,
Laxman