This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LMK03318: PDN timing and function for I2C interface

Guru 19645 points
Part Number: LMK03318

About LMK03318 power supply ON, I2C interface occur not ack received in very rarely(about 1/10000) .

(It was the same result for PDN: H ⇒ L ⇒H)

For measure not ack, please let me know three points below;

①Timing spec for PDN_Low time

 (I want to know required minimum Low time for PDN: H ⇒ L ⇒H)

②Required delay time for I2C communication after reset released (PDN: L ⇒H)

③Because of not ACK is very rarely, I think that measure is below plan.

 ⇒When ACK not received, I2C communication is restart by reset again (PDN: H ⇒ L ⇒H)

 Is thin plan correct? If there any other idea, please let me know. 

Best regards,

Satoshi

  • Hi Satoshi-San,

    I believe there is another active thread regarding the same issue: e2e.ti.com/.../705506

    Our suspicion is that an earlier generation of the silicon may be causing this issue. Can you please provide the date code of the samples that you have?
  • Arvind-san

    Thank you for reply,

    Yes, your thinking is correct.
    This thread is the same issue.

    Already device data code is send by the another thread.
    If ①~③ and additional question(below) are not relation from data code, please let me know.

    【Additional question】
    ④When compare register Read and Write, R142 was only difference (Write : 00h、Read:ffh).
    Is this result normal operation?
    And, the other than R142 register are same as read and write, is it correct operation?

    Best regards,
    Satoshi
  • Please see my reply to the other post: e2e.ti.com/.../705506

    Regarding your additional questions:
    1. PDN low time should be at least 200 ns.
    2. Wait at least 200 us for I2C to be available after PDN goes high.
    3. This workaround is OK for the early silicon, which exhibits the PDN startup issue (explained in the other E2E post). However, the current production silicon has robust PDN startup functionality, so this workaround is not necessary.
    4. This is expected behavior. Writing to R142 (RAMDAT) auto-increments the internal pointer to the SRAM memory address R139:R140 (MEMADR[11:0]). For example, if you write 0x00 to RAMDAT with MEMADR = 0x00C (SRAM address byte #12) and you read-back the value from RAMDAT, you will read the SRAM data from address byte #13 (instead of byte #12) since the MEMADR value was internally auto-incremented by 1. To read the SRAM data at address #12, you need to write 0x00C to MEMADR before reading RAMDAT.

    Regards,
    Alan
  • Alan-san

    Thank you for reply,
    Sorry for additional question, is there below information?

    ・About your answer ④, the other than R142 register are same as read and write, is it correct?
    ⑤Datasheet P52 NOTE is described "The first I2C transaction after power cycling LMK03318 should be ignored".
     What command should first I2C write?
    ⑥Is there any problem the other than PDN for early silicon revision?
     Please let me know about all changed point for early silicon revision.

    Best regards,
    Satoshi
  • 4. Yes, you are correct.
    5. The 1st I2C transaction after power-cycling can be a read operation, such as read from R0. The read data can be ignored.
    6. Besides the design fix to make PDN robust and REVID register reset value, there is no other problem or change from early silicon revision (REVID = 0x01) to current production silicon revision (REVID = 0x02).

    Regards,
    Alan
  • One clarification to #4: Reads from R141 (NVM/EEPROM data), R142 (SRAM data), or R143 (ROM data) will depend on the value written to R139:R140 (MEMADR_BY[1:0]) and whether the internal pointer was auto-incremented. If the customer is writing the registers to configure the device after every power-up (not using NVM/SRAM/ROM), then they can ignore register reads at registers at/above R135.

    Regards,
    Alan
  • Alan-san

    I appreciate your support;

    About answer ⑤, please let me reconfirm about "1st I2C transaction".
    Is LMK03318 move R0 read operation regardless of 1st command?
    I think that send twice wanted to commands on 1st command, is it correct?

    Best regards,
    Satoshi
  • Yes. The suggested I2C programming procedure after power-up is:

    1. Power-up device (VDD and VDDO rails).
    2. Toggle PDN low to high.
    3. I2C read from R0. The 1st I2C transaction after power-up (either dummy read or write) should be ignored.
    4. I2C read from R0 and check for ACK or NACK.
    - If NACK is detected (due to risk of PDN startup issue in early silicon rev only), then go back from Step #2.
    - If ACK is detected, then continue to Step #5.
    5. I2C write the desired register configuration settings.
    6. If needed, toggle RESETN_SW bit to re-calibrate PLL(s).

    Alan