SPE: GTE provided TSC have unexpected values

Continuing the discussion from SPE: GTE provided TSC sometimes goes backwards:

Hello,

The linked post was not resolved but auto-closed. The issue is still pending a reply.
Feel free to re-open the closed thread (and delete this one), or to move new updates to this one.

We understand that more time is required to work on it. Getting an estimate on how long this will take would be appreciated. The ticket has been around for a bit over 2 months, and we gained very little visibility on the outcome.

Best regards

Hi @jachen,

Would you have an update on this ticket?

Regards

Hello, maxe777:
I’m still working on it.

br
ChenJian

Ok, got it. Thanks @jachen

Hi @jachen,

I assume more time is required for the investigation, right?
Looking forward to an update.

Hi @jachen,
Would you have a status update about this ticket? Thanks

Hello, maxe777:
Sorry for so long delay. We are still working on it.

br
ChenJian

Posting here to make sure this ticket stays open

Hello,
Sorry for delayed response. So far, please occupancy as 1, and SPE FW should be able to get TS from GTE correctly.
For other configs, we still need more time.
Thanks for your understanding.

br
ChenJian

Hi @jachen,

Thanks for your message. I understand more time is needed.
Since this ticket is about going over the FIFO, I leave this message to avoid the auto-close while the investigations are ongoing.

Hi @jachen,

Just posting to make sure the auto-close does not kick-in since this ticket is not yet resolved.

Any chance to get some visibility on your timeline? This issue has been reported more than 5 months ago by now. You confirmed you could reproduce the issue. Is there anything we can help with?

Kind regards

This ticket is still open. Looking forward to you support. Thanks.

This ticket is still open. Please share a time estimate once you have more visibility on your schedule.

Looking forward to your follow ups.

Hello, maxe777:
Sorry for that long time delay.

Here are the explanations for the issue you met.
In Orin, GTE only records lower 24 bits (from TSC) in FIFO, and when the timestamp read from GTE FIFO, the actual value is (TSC higher bit) 55:24 + (GTE FIFO counter) 23:0.
Some algorithms are introduced inside GTE for the final timestamp when GTE FIFO is read.
In a simple word, software should read the GTE FIFO within 0.268 second (In Orin, TSC is running at 31.25MHz).

So back to the problem you met.

  1. When occupancy is set by 1, SPE firmware can always read the GTE FIFO in time. So no error’s observed. If you add more delays inside ISR, you may also get the wrong timestamp.

  2. The situation may be much worse when occupancy is set more than 1, since for multiple events, the delay is much higher, and when timestamps in GTE FIFO are retrieved, high bits (TSC 55:24) may vary. That’s the error you observed.
    In such case, you may still have to
    2.1 record every event timestamp (TSC) in ISR, which should guarantee the delay within the value mentioned above.
    2.2 when retrieving multiple timestamps in GTE FIFO, correct the timestamps with the value in 2.1, since only the lower 24 bits in GTE FIFO is trustable.

Hope that explains.

br
ChenJian

Hi @jachen,

Thanks a lot for your detailed answer. That would match my initial observation that somewhat above ~250ms things starts to look worse.

I now tested on the latest Jetpack release (L4T 35.4.1) and I wanted to validated if using only the lower bits would give the expected data.

I did not go back yet to a minimal sample to validate but I’m observing missed samples, even when the time between the events is < 0.268s. The higher the time interval, the more missed events (even with the occupancy set to 1).

With events spaced by 10ms, I still observe the issue (seldomly, but it is present).

I can check more carefully, but I wanted to first double-check with you if you noticed anything, or would be aware of any change in recent Jetpack version which would have change this behavior.

Regards

Hello, @maxe777 :
I don’t think Jetpack version will impact GTE function, though I’ve not tested those version one by one.
You can provide more details if you still think there’s anything wrong.
Please attach logs with both timestamp in GTE and TSC (read by software) if weird timestamps from GTE are observed.

Still, a simple sample may be needed to narrow down the issue.

br
ChenJian

Hi @jachen,

Ok, once I have a bit more time to come back on this, I will run minimal tests and post logs.

Best regards

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.