PROCESSOR-SDK-AM64X: understanding Isochronous PROFINET API (4.0.3) IRT - timing, PINs

Hello Dominik

Providing answer to your queries below

Dominik Fischer said:

• those two signals seem to be the ones triggered from PN_API_IOD_activateIsoGpioObj()?
• so they are the pulses for TI and TO ?!

Yes, these API's are called to initialize the GPIO events for Ti and To signals.

Dominik Fischer said:

Is there any PIN/possibility to get IRT interrupt/ISR without delay?

Could you clarify by IRT interrupt do you mean interrupt for CPM/PPM frames? There are ISR's present for CPM/PPM as "PN_cpmIsrHandler" and "PN_ppmIsrHandler". You can refer to this API documentation on PROFINET FWHAL for further details. 

https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am243x/09_02_00_15/docs/api_guide_am243x/group__INDUSTRIAL__COMMS__PROFINET__DEVICE__FWHAL__MODULE.html

Dominik Fischer said:

• shouldn't PN_APP_IOD_cbDataWrite() be called in TI
• and PN_APP_IOD_cbDataRead() be called in TO

I will have a look at this delay and it's correlation with Ti and To events. Will soon provide an update regarding this.

Dominik Fischer said:

Do you have any guideline/documentation about Profinet IRT device and how to integrate in Application using the full protocol stack of TI?

You can refer to the documentation on the demo app using the below link. Kindly let us know if you need any specific details on any topic.
https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am243x/09_02_00_15/docs/am243x/profinet_device/index.html

Regards,
Laxman

Hello,

Laxman Chinnannavar said:

I will have a look at this delay and it's correlation with Ti and To events. Will soon provide an update regarding this.

Any news on this topic according to TI and TO and the callbacks and the correlation to data callbacks?

Laxman Chinnannavar said:

Could you clarify by IRT interrupt do you mean interrupt for CPM/PPM frames?

Sure, with IRT interrupt I mean the Interrupt/Signal at T_DC. So as far as I understand PROFINET IRT it would be required to trigger the measurement in the device at the yellow time (see below). And then at time TI the measurement values need to be ready to be sent to PLC.

As a workaround I tried to use:

But than the GPIO is triggered only every second cycle (I don't know why?):

Laxman Chinnannavar said:

There are ISR's present for CPM/PPM as "PN_cpmIsrHandler" and "PN_ppmIsrHandler". You can refer to this API documentation on PROFINET FWHAL for further details. 

https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am243x/09_02_00_15/docs/api_guide_am243x/group__INDUSTRIAL__COMMS__PROFINET__DEVICE__FWHAL__MODULE.html

I also took a look at the suggested CPM and PPM functions, I registered callbacks. However they never have been called, so this I guess is not what I was searching for.

A new topic also came up: As I might run out of pins on final device I tried to call TI and TO via the ISR API interface. In isrTo() and isrTi() I toggled a PIN to see when they are called. However, both seem to be called at the almost same time and not when TI and TO were configured. 

Please let me know if you need any further information.

Thanks in advance for your support!

Kind regards

Dominik Fischer

Hi Dominik,

Apologies, there will be delay in supporting this query due to an unexpected issue. We will provide a response as soon as possible after reviewing the issue in detail.

Regards,

Laxman

Hi there,

It's been some time since the last responses ...

Do you have any hints/answers how to handle IRT properly in application and especially answers to the asked questions?

Hi Dominik,

Apologies for the delay, we will start looking into this problem now by performing similar experiment to understand the timing issues. We will provide an update on the status soon.

Regards,
Laxman

Thank you! This would be great, then we could proceed with our implementation in application

Hi Dominik,

We had run some tests previously and also found out that the ISR event for ISOM are not called at correct intervals. I will debug this issue in detail and provide an update once we figure out the root cause.

Regards,
Laxman

Hi,

we are still waiting for an update on this issue. Can you provide any information?

Regards,

Dominik

Hi Dominik,

We have figured out the issue with respect to ISOM ISR and found a bug due to which for both Ti and To interrupts are called regardless of whether Ti/To event is triggered. We are currently implementing a fix and will be testing this with our setup soon. Will keep you updated with the test result.

Thank you for your patience.

Regards,

Laxman

Hi Dominik,

We have reviewed the implementation of ISOM interrupt mechanism for both Ti and To events. The current implementation involves handling both Ti and To interrupts via a common interrupt event and distinction between which callback requires to be called is based on the timing of the interrupt. However this approach will not lead to deterministic communication with the timing values provided. 
Hence we are planning for a different approach by having separate interrupt events for both Ti and To. This will ensure the timing of the interrupt to be precise. We are currently implementing this and are planning to complete this by end of next week.

Thank you for your patience.

Regards,
Laxman

Hi Laxman,

maybe you are able to give me feedback. Is there any concrete plan when this fix will be available? We need to plan our product releases and somehow depend on this fix for PROFINET stack.

Kind regards,

Dominik

Hi Dominik,

We were able to segregate interrupts for Ti and To events and are also able to detect the interrupts getting called every cycle. However currently we are observing some delay at startup when the interrupts are triggered. We will be running few tests to check the root cause and soon provide an update with the results. Kindly expect a response by start of next week.

Best regards,

Laxman 

Thanks Laxman, then I hope for the release in near future to finally integrate PROFINET successfully on our device!