TMS570LS3137: Workaround for SSWF021#45 has been updated but it is unclear why

Hi Mark,

We started to work on your issue and will try to provide an update ASAP.

--

Thanks & regards,
Jagadish.

Hi Mark,

I don't have SPNA233A document, do you have this document?

If you have it, can you please share it?

--

Thanks & regards,
Jagadish.

spna233a.pdf

Hi Mark,

After comparing RevA and RevB workarounds, my understanding is below:

They did two main modifications:

1. They reduced the PLL output frequency from Rev A to Rev B

2. They changed the equivalent seed values at measurement:

As we reduced the frequency, the seed values also will get reduced right, that is the reason they reduced CNT0SEED and CNT1SEED values.

I verified all the old threads and documents but i don't have any document or data why this modification is done.

After analyzing the data my takeaway is that the both the measurements are valid because as they reduced the frequency, so they just configured the equivalent seed values. They reduced the frequency because for more accurate measurements, i mean in REV_B work around the PLL output frequency is 4 times less than the frequency in REV_A work around, so that as frequency got reduced obviously the measurement will be more accurate right?

--

Thanks & regards,
Jagadish.

Thank you for your response Jagadish.

We are using the workaround proposed by the Rev A version in a safety critical application so it is important for me to determine whether an update is needed based on the latest revision.

My understanding  from what you have said is that either workaround is suitable and both minimise the PLL startup issue described in Advisory
SSWF021#45, which is in itself rare.

Section 1 of spna233 states that the workaround is not 100% effective, so I assume the reduction of the the PLL output frequency in the latest revision is simply an attempt to further improve its reliability.

Can you please confirm that my understanding is correct?

Thanks,

Mark.

Hi Mark,

Apologies for delay in response, i was stuck with other issues.

Mark Blay said:

My understanding  from what you have said is that either workaround is suitable and both minimise the PLL startup issue described in Advisory
SSWF021#45, which is in itself rare.

Section 1 of spna233 states that the workaround is not 100% effective, so I assume the reduction of the the PLL output frequency in the latest revision is simply an attempt to further improve its reliability.

Can you please confirm that my understanding is correct?

Your understanding is correct. Yes, either workaround is suitable and both minimise the PLL startup issue. Yes, reduction of the the PLL output frequency in the latest revision is for to further improve its reliability.

--

Thanks & regards,
Jagadish.

Thank you for your clarification Jagadish.

I have one additional question that has arisen from our safety assessment.

The workaround attempts to lock the PLL for a specified number of retries. After this our system calls a failure notification function that ultimately results in it being reset by an external watchdog timer. This performs a soft reset, not PORRST.

In the event that the PLL fails to lock after the set number of retries, what is the likely outcome of repeating the sequence following the soft reset?

Will the PLL fail to lock from this point until the next power cycle or is there a chance that the system will recover from this and ultimately achieve lock?

Thanks,
Mark.

Hi Mark,

Mark Blay said:

In the event that the PLL fails to lock after the set number of retries, what is the likely outcome of repeating the sequence following the soft reset?

Will the PLL fail to lock from this point until the next power cycle or is there a chance that the system will recover from this and ultimately achieve lock?

It is not possible to do POR from software.

(+) TMS570LS3137: Does TMS570LS3137 has self reset equivalent to Power ON Reset - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

And agreed that soft reset will not reset the device completely like the POR does, but we cannot do POR from software. And we don't have any data as well that soft reset will be helpful to lock the PLL again.

--

Thanks & regards,
Jagadish.

Thanks Jagadish.

The reset is performed by an external monitor. It is initiated by the software entering an infinite loop and waiting for the watchdog to time out. However the reset is not using PORRST.

So from your post this will not help us as once the PLL has failed to lock we will need PORRST before it is possible to lock again.

Mark Blay said:

So from your post this will not help us as once the PLL has failed to lock we will need PORRST before it is possible to lock again.

You are right Mark.