LMK04832: Wrong hex register values in the exported file with TICSPro v1.7.7.10

Hi Luca,

I can see your issue but I was unable to replicate it in my own version of TICS Pro. Can you try redownloading TICS Pro?

https://www.ti.com/tool/PLLATINUMSIM-SW#downloads

Thanks,

Michael

Hi Michael,

   I have tested again with a brand new v1.7.7.10 installation.

   Same results.

   I attach my project so that you can experiment with it.

lmk04832-a40.tcs

This is an irritating and subtle bug that shows up when newer versions of a profile change the ordering of the registers in the raw registers page, combined with another irritating decision made years ago to mix the protocol into the exported data as one concatenated number.

Older versions of the LMK04832 profile used to have a different register order, which placed the whole N-divider (R358, R359, R360) at the back of the register map. This was done for several reasons:

• The order in the register map also dictates the order used by write all and read all register operations.
• The PLL2_N divider LSBs trigger a VCO calibration when written.
• The bits controlling the power to the PLL2 elements like the charge pump, VCO, and post-divider are all in a later register (R371).
• Several of the default POR states for these bits prevent the calibration from ever completing successfully

This creates a race condition when the registers are written between the calibration event and the subsequent fields that can interfere with the calibration. Interference with the VCO calibration degrades the phase noise and temperature stability. The quick workaround was to place all the registers containing PLL2_N at the back of the register map.

However, only the LSBs of PLL2_N (R360) trigger calibration when written. So there is no need to out-of-order R358 or R359, and these were moved back at some point when the other devices in the LMK04832 family (LMK04832-SP, LMK04832-SEP, LMK04368-EP, LMK04714-Q1) were being released.

In a better universe, we would have stored the address and data components separately. Instead, TICS Pro exports both .tcs files and hex register exports with the address and data components packed together, as though the components were being serialized for protocol writes. Because no one ever considered what would happen if the order of registers in old configurations and register exports did NOT match the order of registers in new configurations, for several iterations TICS Pro would naively assume that the name of the register (e.g. R388) was always correct. Consequently, when loading configurations or hex register imports, if the register name did NOT match the value (e.g. 0x16600), we loaded the whole value to the raw registers page, including the incorrect address component. This could subsequently be exported with mismatched register names and propagated to other TICS Pro instances, and generally caused chaos until the cause of this mess was discovered and patched.

In modern versions of TICS Pro, the following behaviors are expected:

• Mismatched name/value in TCS file: name is ignored, address component is deserialized from the value, register is loaded to a matching address if one exists or is skipped at the end with a notice in the activity log.
  • I confirmed this behavior is working as expected by loading your TCS file into TICS Pro 1.7.7.10. I observe in your TCS file that the data includes several incorrectly-labeled registers (R358, R359, R360); however, the activity log correctly documents the correct values for these registers when writing them during the loading process. It also skips now-missing registers R364 and R365, which were presumably removed during the profile updates described above.

  • ...
    [MODES]
    NAME00=R0 (INIT)
    VALUE00=144
    NAME01=R0
    VALUE01=0
    ...
    NAME119=R386
    VALUE119=98816
    NAME120=R387
    VALUE120=99073
    NAME121=R358
    VALUE121=91648
    NAME122=R359
    VALUE122=91904
    NAME123=R360
    VALUE123=92161
    NAME124=R1365
    VALUE124=349440

  • 
• Mismatched name/value in hex file: Similar behavior, but documents the mislabeled registers.
  • Again, I confirmed this behavior is working as expected by loading your mismatched hex export file into TICS Pro 1.7.7.10.
  • 

The behavior of TICS Pro 1.7.7.10 is as expected, and I do not see any erroneous mismatches between names and values being propagated out of 1.7.7.10 by save or export.

So, how could it be the case that modern versions of TICS Pro are producing the incorrect behavior?

• Are you certain you are using the version of TICS Pro you think you are using? You can check the version in the Help -> About TICS Pro menu.
• Are you using a custom "user device" profile, instead of the normal profile? User device profiles show up under the Select Device -> User Devices submenu; if this submenu is grayed out, you are using the built-in device profile, eliminating this possibility.
• TICS Pro saves a state file between sessions. This saved state should be treated identically to TCS files, but I do wonder if somehow that file is related. You can try deleting this file - it's located at "C:\ProgramData\Texas Instruments\TICS Pro\Configurations\Devices\Clock Generator-Jitter Cleaner (Dual Loop)\LMK04832\LMK04832.tcb"

Hi Derek,

    thanks for your explanation.

    - I am using TICS Pro v1.7.7.10: checked About TICS Pro menu and also window pane at startup.

   - The "user device" is grayed out, so the built-in device is used.

   - I have deleted the .tcb file, restarted TICS pro and load project tcs, export to hex => same output file.

     I have noticed that the .tcb has been created again, and it is identical to the deleted one.

Very interesting. Can you scroll to the bottom of the Raw Registers page and take a screenshot?