LMK03328: DEV_CTL Register

Yokohara-san,

Is there any time delay between issuing steps 2/3/4? Or are these all one right after the other?
Thanks,

Kadeem

Kadeem,

Thank you for your reply.

The waiting time between each step from step2 to step4 is 10ms.

These are all one right after the other from step1 to step4 for our device configuration.

Best regards,

Yokohara-san,

Are you seeing an "ACK" from the device when writing 0xD9 in the failed cases?

In the failed cases, are you seeing the output clocks come back on when 0xD9 is written?

Does a subsequent write of 0xD9 resolve the issue, or does it ignore all 0xD9 writes to this register?
Thanks,

Kadeem

Hi Kadeem,

>>Are you seeing an "ACK" from the device when writing 0xD9 in the failed cases?

Yes, we always check ACK in I2C transactions.

>>In the failed cases, are you seeing the output clocks come back on when 0xD9 is written?

No.

>>Does a subsequent write of 0xD9 resolve the issue, or does it ignore all 0xD9 writes to this register?

The probability that data 0xD9 is not reflected in the register is 1%.

When we tried from step1 to step4 2000 times, 0xD9 was not reflected and kept 0x59 20 times.

Best regards,

Yokohara-san,

Thank you for letting me know this information. 

If the delay time time is increased (on the order of 10 ms -> 25 ms), is this behavior still present?

We have not heard of this issue being reported either internally or from other customers.

When we toggle this bit in TICS Pro, there does not appear to be any added delay, only the delay between instances of commands being issued.
Is toggling the PDN pin an option for performing the software reset in place of toggling this bit>

Thanks,

Kadeem

Hi Kadeem,

Thanks for your quick response.

We try to extend the delay from 10ms to 25ms and evaluate again.

[Q1] Does 25ms mean anything? (for example: internal timout process etc...)

 And, there are several additional questions.

[Q2] Which is LMK03328's ACK output timing "I2C communication finished" or "internal processing finished" ?

[Q3] Does ACK output timing change due to LMK input clock behavior?

Best regards,

Hi Masaki,

Kadeem will get back to you tomorrow.

Best,

Evan Su

Yokohara-san,

1. There is not anything incredibly specific with this timing - do you have multiple parts that experience this issue, or just one? I am going to recreate this methodology this week on one of our EVMs and see if I also see this issue.

2. The ACK timing is an acknowledgement that a "valid" I2C transaction is received, valid meaning that some transaction assessed to the device with the correct number of bits was received, not that the data is valid for a specific register.

3. The ACK timing is independent of the input clock to the device.

Thanks,

Kadeem

Hi Kadeem,

I'm sorry for my late reply.

I will check if another part has this same issue next time.

Best regards,

Yokohara-san,

Please let me know as soon as you find out.

I will update you once I have results on my end.

Thanks,

Kadeem

Hi Kadeem,

I'm sorry but, there is no definitive information of whether the same phenomenon occurred with multiple parts.

I'm currently using the test environment for a different purpose, so I'll check it on multiple parts later.

Best regards, 

Hi Yokohara-san,

Thanks for the update. Kadeem will get back to you after the July 4th holiday.

Best,

Evan Su

Yokohara-san,

I am not seeing this behavior on my parts in the lab.

I will reach out to the design team for more information.

Thanks,

Kadeem