Hi Riley

Thanks for your reply. If one looks at the contents of R10 and compare it with EEPROM byte 10 then the data matches per expectation. Thus is seems strange that two bytes further on there is a lack of correlation. So where in the EEPROM map file can i find the byte which holds the content of R12?

Ian

Hi Ian,

We have this register map: LMK05318B register map. Please see if it helps.

-Riley

HI Riley

That map does not capture the bit assignation of the registers in the EEPROM.

Ian

Hi Ian,

We don't have EEPROM map published yet. I've discussed with our team on this request and we will look into publishing this document.

-Riley

Hi Riley

Thanks -- do you have a timeline for that? The TICs GUI allows the EEPROM MAP to be exported, but its not much use if we cannot decode its contents.

Ian

Hi Ian,

We're still discussing on some info regard this EEPROM map and not yet concluded on timeline. May I know the project and volume so we could rearrange on priority?

Regard Byte #12 of EEPROM, it contains field bits of device register R15[4:2] and R12[5:3]

Note that device register R12[7:6] are not in EEPROM.

-Riley

HI Riley

Thanks for revealing the content of EEPROM at its address 12

I am not able to share product details in a public forum, so if I somehow need to make a case to get data which you surely must already have, then please send me an email

Further can you explain the purpose of the registers which hold PLL1 NUM STAT -- these are not mentioned in the data sheet. I am interested to know why the values read back from a programmed device to not compare to our programming file. 

Same question goes for PLL1_CP_BAW, where the register map does not clearly define the bit assignations.

Thanks

Ian

Hi Ian,

I'll jump in here--PLL1 NUM STAT is used to readback the the APLL1 numerator when the DPLL is enabled and PLL1_CP_BAW is a factory-programmed value used to tune the BAW VCO in APLL1.

Regards

Jennifer

HI Jennifer

Thanks for sharing this information, Another question, Register 346 bit 1 is set to reserved -- what would happen if we wrote a 1 to it in addition to writing a 1 to bit 0 to enable DCO mode?

Ian

Hi Ian,

If you write a 1 to R346 bit 1, then increment/decrement updates through the GPIO signals are ignored and the DCO registers are used instead.

Regards,

Jennifer

HI Jennifer

That seems to conflict with the published data which says bit 1 is reserved

Ian

Hi Jennifer

I am confused.

The default in R346 seems to be A2. when I tick DPLL_FDEV_EN the value changes to A3, So to me the manual seems ok. My original question related to the significance of bit 1 which is set by default to 1.

From the GUI GPIO FDEV is enabled in R50.

Ian

Hi Jennifer

Would you be able also to clarify the bit assignations for R68 including reserved?

Our Hex program has this

and sometimes on read back we see "28" and sometimes "08"

What does the "2" signify?

Ian

Hi Ian,

1. Where do you see that R346[1] is set to 1 by default? It should be 0.
2. DPLL_FDEV_EN is indepdent of R346[1] because DPLL_FDEV_EN is bit 0.
3. Can you please share your .tcs file? I can take a look at your bit settings.

Regards,

Jennifer

Hi Jennifer

Please respond to my question above on bit assignations in R68

Thanks

Ian

Hi Ian,

Please share your .tcs file for me to confirm those bit settings are correct.

We have those bits marked as reserved for customer use.

Regards,

Jennifer

Jennifer Review.tcs

Hi Ian,

Let me review this.

Regards,

Jennifer

Hi Jennifer

I dont think we specifically wrote that bit in our file. There are no selections in TICs GUI to set it as far as I am aware. Since its a reserved bit, then we have no way of knowing what its functionality is.

When you say the bit gets set -- by what mechanism does it get set?

What we see is that with the bit in our programming file, sometimes it gets programmed as per the file and sometimes when we read back, that bit is not set.

Ian

Hi Ian,

As mentioned, this bit is not meant to be manually configured. Instead, you should rely on the recommended setting by TICSPRO. When you run through the LMK05318B wizard and enter the reference frequency in the boxed region from the picture, the R68 bit 5 gets set accordingly.

I'm confused how sometimes it's readback and not set to 1 even though the programming file sets the bit to 1. Can you please elaborate how you program the LMK05318B? Do you mean the EEPROM at power-up or only through direct I2C communication? What are the steps you use to load the configuration file onto the part?

Regards,

Jennifer

HI Jennifer

Thanks for explaining how the bit gets set. We program the device by using the hex file generated from the TCS, then using the TICs software, write to SRAM and then to EEPROM in the standard way. Somehow when the issue happens that is the only register that changes. I have seen this on devices which use a different file which calls for the "08" setting. After programming the R68 instead of reading 08 gave 14. It seems there is some intermittent issue relating to R68 which I have now seen across quite a few devices. 

Hi Ian,

Let me try to reproduce your issue. Do you program the EEPROM using TICSPRO or your own I2C drivers/software?

Regards,

Jennifer

HI Jennifer

Per my email above, we use TICs pro to program EEPROM. I notice that when using the hex file as the source of programming data, that the GUI does not completely update for all screens. For example if we have been programming another device which uses a 25M reference and then load the hex bytes for the file I shared with you which has a 156.25M primary reference, then the reference frequency does not update.

When programming using a hex bytes file can the GUI impose settings of its own perhaps?

Ian

Hi Ian,

Thanks for clarifying the procedure.

Yes, loading the .hex file does not update the TICSPRO GUI settings. If using TICSPRO to program the EEPROM, it is recommended to load or generate a .tcs (TICSPRO) file instead of relying on the raw hex register settings. This is because the Program EEPROM function in TICSPRO checks the GUI settings. 

If you program with a .tcs file instead of .hex, do you still see the issue with R68 changing across EEPROM programming cycles?

Regards,

Jennifer

Hi Jennifer

Regarding programming from a tcs file, I will need to gather more data, as I cannot say for sure that it is entirely ok.

By the way do you have any PC based utility which could do hex file programming? We have no plans at the moment to do programming at run time in our host system, but wondered if you had something which would allow us not to use TICs software.

Ian

Hi Ian,

Do you mean with the USB2ANY? We have a portal available that can let you interface with hex registers. Refer to the the USB2ANY explorer zip file install here: www.ti.com/.../USB2ANY.

Regards,

Jennifer

Hi Jennifer

I tried downloading this explorer, but it would not run on my PC

What I mean is a utility in say Python that will run on a PC and will download a hex file to the LMK05318B and program to EEPROM,

Meaning it does what the TICs software does to program the device EEPROM.

Ian

Hi Ian,

We do not have that .hex to EEPROM function available at this time.

Regards,

Jennifer

Hi Jennifer

Coming back to the use of hex bytes vs TCS file as the source for EEPROM programming, we find that even using TCS, the GUI sometimes does not populate correctly, with target frequency incorrect and also some outputs turned off and not showing their values.

Any idea why this should be happening and do you have any workaround?

Ian

Hi Ian,

When configure tcs file, after calculating the frequency plan, you would need to do "Write all Regs" and "Soft-reset Chip" so that all registers are written properly for the correct output frequency.

-Riley

HI Riley

thanks for your reply. If we already have a TCS file which contains all the parameters we need for a given plan, why do we need to calculate the plan again when using that file to write to the device EEPROM? If your instructions are followed, will that ensure that the TICS Pro GUI is correctly populated with the frequency plan details?

Ian

Hi Ian,

If you already configure all parameters, no need to calculate the plan again but still necessary to do "Write all regs" and "Soft-reset chip".

-Riley

HI Riley

My question was around what we see in the GUI of TICS Pro -- so are you saying that it is necessary to write all registers and do a soft reset to get the TICS PRO GUI to show the correct data?  To re-emphasize I am asking why the GUI does not always display the correct parameters after loading TCS file, I am not asking about writing of information to the device.

Ian

Hi Ian,

Which parameters from your config isn't updated on TICS Pro GUI? If possible please share the tcs file so I can duplicate it on my end.

-Riley

HI Riley

If you look back on this thread you will see that I have previously provided a file for Jennifer.

Ian

Hi Riley

Did you manage to look at the file? 

Ian

Hi Ian,

I see the GUI shows frequency output on OUT2-3 although they are disabled. But it would not affect output performance. There is a function on TICS Pro to handle updating GUI so you could also use the Calculate frequency plan button to aid the GUI update with frequency plan.

-Riley

HI Alex

I would expect that if a saved project file is loaded into the TICs software that everything should display correctly.

We use this software in production to program PLLs on our boards prior to full product functional test. I don't want test technicians to be calculating frequency plans, I just want programming to work with 100% confidence that device EEPROMs have the correct content.

What can TI do to make this software perform as such?

Ian

Hi Ian,

I would use the GUI to update the config so all registers including GUI are properly updated within the config, save this freshly generated config to use for future program. This way, the test tech doesn't have to re-calculate plan each time the device is loaded with the config.

-Riley

Hi Riley

So are you saying that the file I pointed you to review did not have all the correct parameters in it already?

Ian

Hi Ian,

No, the config I checked is working that output clock is correct and device locks. But if OUT2-3 GUI error is the concern, I would suggest to update with TICS Pro GUI.

-Riley