• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 22 subscribers
  • Views 535 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: EEPROM hangs when trying to store from SRAM

Anton Grounds
Prodigy 30 points
Part Number: LMK03318
Other Parts Discussed in Thread: LMK04832

HI,

I am writing a kernel drive to program the LMK03318 clock chip over i2c.

I am able to write to the registers and they cause a corresponding change in the live output of the chip.

For completeness, I am using the i2c_master_send for sending single bytes and i2c_master_recv to receive single bytes (No burst mode yet).

My I2C clock is 400kHz on the bus.

I am able to write to any individual register and read it back to confirm correct write operation.

I am also able to write to the SRAM directly using the excel doc (3857.LMK033x8_EEPROM_programming_v1) as the generator of the address value pairs with the EEPROM file being generated by TICS.

I can confirm the correct SRAM by reading back the values and comparing them to the original values.

My issue comes when I try to set the SRAM into the EEPROM.

We are in soft pin mode with GPIO 2/3 both set to ground.

I have tried following the 10.5.4 Write SRAM section of the PDF.

I have tried the first method described by writing all the registers I need to set and confirming live operation.

Then writing 0x00 to R145 to set page 0. 

Then writing a 1 to R137.6 to copy the live registers over to SRAM.

I then follow section 10.5.5 Write EEPROM.

Write 0xEA to R144 to unlock the EEPROM

Write a 1 to R137.0 to start the transfer.

I did use to relock the EEPROM again after waiting 400ms but I don't right now as I wasn't sure if it was causing the write to fail.

I have also tried the second method of writing to the SRAM first and I can confirm that the values took as I can read them back.

I then follow section 10.5.5 Write EEPROM as described above.

What happens is R137 never clears it stays 0x01 forever until I power cycle.

This is a before image with the EEPROM counter, NVMCTL and NVMUNLK registers circled.

This chip was programmed once by the TICs program directly before it became embedded in the system.

After performing the EEPROM write steps above.

7

You can see that the NVMCTL reg is stuck on 0x01, the counter is still at 0x01 and the unlock is currently "unlocked" at 0xEA.

Sorry that this is a long post I just wanted to cover everything I could think of.

Hopefully, someone can help.

Cheers

Anton

  • 0
    Prodigy 30 points

    Some things of interest.
    When probing, with a logic analyzer, the TICS output through the EVAL board for the chip, I notice it doesn't program the chip in the way described in the doc. It writes to a lot of the reserved addresses, and on the EEPROM program it does the following;

    So it writes to store the live registers and autocalc CRC to register 0x89, then it immediately clears the value back to just autocal CRC so it doesn't wait for the self clear.

    It then unlocks the EEPROM.

    Then it starts the programming of the EEPROM with 0x13 which is the autocalc CRC and one reserved bit with no description 0x2 and the 0x1 program EEPROM bit.

    Then it locks the EEPROM after only a 30ms delay (measured time)

    And finally, like how it forces the 0x89 register to clear, it then forces the EEPROM write bit to clear and doesn't wait for it to auto clear.

    So it seems like TICs has a different sequence to the documentation.

  • 0 in reply to Anton Grounds
    TI__Genius 16515 points

    Hi Anton,

    Let me check with the team on this.

    Regards,

    Jennifer

  • 0 in reply to Jennifer Bernal
    TI__Mastermind 22340 points

    Anton,

    You could follow the steps that TICS Pro uses, if those work for you.

    What I am able to do is the following - please try this procedure in TICS Pro in the "Raw Registers" window and let me know what your result is.

    1. Write your desired configuration to the active device registers.
    2. Write R145[3:0] = 5 (R145 = F6h in my case, I am using SRAM/EEPROM page 5, but I also tried this with page 0, in which case a 0 would be written here. I have GPIO2 = GPIO3 = H for 5, or both L for 0)
    3. Write R137[6] = 1 (R137 = 50h)
    4. Write R144 = EAh
    5. Write R137[0] = 1 (R137 = 51h)
    6. Write R144 = 00h
    7. Read R137 - despite what the datasheet says, I am reading back 50h rather than 10h.
    8. Power cycle the part
      1. The part comes on with the settings that I configured.

    One thing that I would like to note (both for you and future readers of this thread) is that if you are programming multiple pages, you have to repeat steps 1 through 3 for each SRAM page. If this is not done, any other EEPROM configurations that may have been previously stored in other pages will be overwritten.

    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    Prodigy 30 points

    Thanks for the feedback Kadeem.
    I will try what you suggest tomorrow.
    I will ultimately need to be able to program the EEPROMS without using the EVAL board but its a good place to try your approach first.
    The main thing I can see that's different to how I've tried to already is the programming of 0x51 at step 5 where I would normal program 0x1 or 0x11 if I wanted auto CRC enabled. 
    Ill let you know how I get on. 

  • 0 in reply to Anton Grounds
    TI__Mastermind 22340 points

    Anton,

    Good - please let me know if this method does not work properly for you.


    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    Prodigy 30 points

    So the EVAL kit works ok. Its sometimes a bit fickle where after programming it doesn't look quite right on the outputs tab. So I have to select program all registers twice and then run through your steps and that seems to stick so that's good.

    So moving this forward to allow me to program the EEPROM from within our product which doesn't use the eval board...

    I have my logic analyzer hooked up to the chip in both environments, under eval (outside our product) and inside the product. I do notice that there is I2C traffic on the bus while waiting for the EEPROM to program. Nothing talks to the LMK directly but the bus might be active during the 230ms wait.
    How critical is it that the i2c port must be totally quiet while programming the EEPROM step?

    I get that its listed as atomic writes and that's fine I can guarantee that nothing is talking to the chip except my driver and that I don't talk to the chip for 300ms (I add a buffer of time) between the steps of set 0xEA, Set 0x51, set 0x00 sequence. But I did see in another thread on this forum that a technical response was that NO traffic should happen on the port after starting the EEPROM write. Is that really the case that the port must be totally quiet of all i2c traffic?

    If so I might need to look into some kind of bus lock during that period to stop any traffic on the i2c bus.

    Thanks again for your time.

  • +1 in reply to Anton Grounds
    TI__Mastermind 22340 points

    Anton,

    This is correct - there should not be any traffic on the bus during this time.

    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    Prodigy 30 points

    Just a follow-up here for anyone reading this later.

    The root cause is that because the LMK chip is behind a mux, the default state for the Linux kernel i2c driver is to close and open the mux between any transfer. This opening and closing is acceptable for all LMK operations EXCEPT the EEPROM write command, as that requires the I2C bus to be totally quiet for 230ms.
    So you need to mux lock the i2c mux during the read or write sequence such that you can write the program command and then wait 230ms holding the bus in lock. 

    After doing this I am able to program the clock both using the write to live reg then copy to SRAM and also direct SRAM write before save to EEPROM. 
    This allows me to continue with my kernel driver for the lmk03318. I am creating it under the GPL license so it might end up joining the lmk04832 under kernel source.

    So I'm accepting your response Kadeem. Thanks for the help.