LMX2492EVM: Inquiries

Ah, I get it now. Note the literature number in the customer's links are the same, just at different revisions. The SNAU160E board is the current revision of the EVM. The SNAU160C board is a prior revision of the EVM. We had to make BOM changes and stop populating the VCO due to obsolete components, and this resulted in a board layout change to accommodate a new component with a different pinout. The original RFVC1843 used in the arrow EVM is discontinued, so I don't think it will be possible to get this component any more. I'm not sure there are any suitable replacements, and I don't think we've looked for any since the latest revision in 2017, so there may be newer alternatives; but the board revision with the RF/4 wiring is no longer available and has been out of stock for a long time. I could look for the layout files if they wanted to build it themselves...

No video or tutorial for how to populate external VCO, but I can provide basic instructions:

• For 14V control, they need a suitable amplifier. The LME49710 actually went EOL a few years ago, but LM6211 is still in production with RRO and up to 24V supply. Since op-amp pinout is fairly standard, there may be better options for this component as well.
• The supply for this amplifier is provided via AmpVcc net, which has a pinout to connect to VccAMP supply net. VccAMP supply net could be generated with LP5900, but 3.3V is not sufficient to drive up to a 14V signal on the amplifier, hence this component is left unpopulated and only provided in case there are configurations which could benefit from it. In practice you would provide the supply externally to the TP_VccAMP pins and connect R54 and C26 to supply power for the amplifier.
• R52/R53 and C25 provide the bias point for the noninverting terminal of the amplifier from the charge pump supply VccCP. With some creativity, R52 could be moved to support a level-shifting gain configuration (Active Type C loop filter in PLLatinum Sim terminology).
• R55 would be populated to link the charge pump output to the inverting terminal of the amplifier.
• There are several filter configurations supported (using filter types as described in PLLatinum Sim):
  • Active Type A: C1_LF and R55 are the first order components, C2a_LF and R2a_LF are the second order components, and R3a_LF/C3_LF/R4_LF/C4_LF are the third and fourth order components. C2_LF, R2_LF, and R3_LF would be left unpopulated.
  • Active Type B: C1a_LF, C2a_LF, and R2a_LF are the first and second order components. R3a_LF/C3_LF/R4_LF/C4_LF are the third and fourth order components. C1_LF, C2_LF, R2_LF, and R3_LF would be left unpopulated.
  • Active Type C is not supported by default, but could conceivably be reworked onto the board with some creativity. Of course, Active Type C is the configuration that allows gain, and that would give the full tuning range for the amplifier... if I were to attempt an Active Type C wiring, I would probably populate R52 connected to AmpVb but not VccCP, and run the VccCP side to the output of the amplifier with an external wire. Then I would use C1_LF, C2_LF, R2_LF, R3_LF, C3_LF, R4_LF, and C4_LF as normal, and leave C1a_LF, C2a_LF, and R2a_LF unpopulated. R3a_LF would be populated with 0Ω.
    
• For the different VCOs that are supported:
  • The U2-style pinout could be left as-is, though VccVCO should be supplied from an external supply of higher voltage, and C3/C4 should be checked for their voltage rating. Additionally, R4/R6/R7 and R8/R9/R10 may be too small for the output power they are asked to deliver. Double-check that these components will not be stressed beyond their rated power dissipation.
  • The U2p-style pinout requires R14/C5 to be populated for the supply voltage, and R4_LF/C4_LF should be substituted with R4p_LF and C4p_LF. R5 should be populated, and R6 should be unpopulated. Additionally, R4/R5/R7 may be too small for the output power they are asked to deliver. Double-check that these components will not be stressed beyond their rated power dissipation.

As long as the customer is comfortable with running TICS Pro in the background to manage the connection between the customer's frontend and the USB2ANY, the TCP server available in versions >1.7.3 provides access to all registers necessary to implement their desired functions.

Regards,

Derek Payne

Danilo,

We don't have any API exposed to allow connecting to the exe directly (except ActiveX, which will be deprecated within 1yr, and requires the other program to run as a 32-bit process).

The logic for the LMX2492 ramp function is actually stored in plaintext as a .py file for evaluation. TICS Pro uses IronPython to directly load python functions into the application scope, to handle some of the logic:

• The ramp calculations should be located in C:\ProgramData\Texas Instruments\TICS Pro\Configurations\Devices\PLL\LMX2492\LMX2492_rampcalc.py
• By TICS Pro convention, functions ending with "_Update" are linked to controls in the GUI. Any time the control is modified by user interaction (mouse control, TCP server control) the update function is called. 
• Controls are given an iValue, dValue, or sValue corresponding to integer, float, or string data types. Register-backed controls with an iValue correspond to the register programming value.
• Whenever we write to a register-backed control with a .iValue update, this is translated to an immediate register write.

I think this should be sufficient to do what they're asking.

Regards,

Derek Payne

Danilo,

US holiday for TI today, so I'll look into this in more detail tomorrow. My "ten seconds of thought" guess is the feedback loop is broken, or the polarity on the charge pump is incorrect. At a bare minimum, I would expect changing the charge pump polarity should force the TUNE voltage to 0V rather than 5V.

As far as setting up USB2ANY manually, we have some documentation in other E2E posts describing how this is done (see the link below, which includes the API manual for USB2ANY v2.7.0.0 bundled with TICS Pro). That said, I've since observed a few errors in how I wrote that program, and it's specific to LMX2594, so I've included an updated snippet after the link.

https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1025934/lmx2594evm-serial-control-through-python

import ctypes
u2adll = ctypes.WinDLL(r"C:\path\to\USB2ANY.dll")

## [Scan available USB2ANY devices]
controllers = []
buf = ctypes.c_buffer(80)
for i in range(u2adll.u2aFindControllers()):
    u2adll.u2aGetSerialNumber(i, buf)
    if buf[0] != b'\x00':
        # USB2ANY serial number response is encoded in 16 bytes
        controllers.append(buf[:16])

# Open a session with USB2ANY. In our example, use the first one.
if not controllers: raise Exception('no USB2ANY found')
handle = u2adll.u2aOpen(controllers[0])

## [Configure SPI bus]
bitRateKbps = 400
divider = int(24000 / bitRateKbps)
dividerHigh = (divider >> 8) & 0xFF
dividerLow = (divider & 0xFF)
errCode = u2adll.u2aSPI_Control(
    handle, 
    1,      #SPI capture on leading edge
    0,      #SPI inactive state low
    1,      #SPI MSB first
    0,      #SPI 8-bit
    1,      #SPI with every packet
    1,      #SPI active low
    dividerHigh, dividerLow)
if errCode != 0: raise Exception('failed to configure SPI bus: ' + str(errCode))

## [Write and Read example]
denominator = 0xFACADE
buf = ctypes.c_buffer(3) #register length is three bytes for LMX2594
packet1 = 0x001500 + ((denominator >> 16) & 0xFF)
packet2 = 0x001400 + ((denominator >> 8) & 0xFF)
packet3 = 0x001300 + (denominator & 0xFF)

# first packet
buf[0] = (packet1 >> 16) & 0xFF
buf[1] = (packet1 >> 8) & 0xFF
buf[2] = packet1 & 0xFF
bytesWritten = u2adll.u2aSPI_WriteAndRead(handle, 3, buf)
# assert bytesWritten == 3

# second packet
buf[0] = (packet2 >> 16) & 0xFF
buf[1] = (packet2 >> 8) & 0xFF
buf[2] = packet2 & 0xFF
bytesWritten = u2adll.u2aSPI_WriteAndRead(handle, 3, buf)

# third packet
buf[0] = (packet3 >> 16) & 0xFF
buf[1] = (packet3 >> 8) & 0xFF
buf[2] = packet3 & 0xFF
bytesWritten = u2adll.u2aSPI_WriteAndRead(handle, 3, buf)

# readback example - we will read 0x13
buf[0] = 0x00 | 0x80 # high bit is 1 for readback
buf[1] = 0x13
buf[2] = 0x00
bytesWritten = u2adll.u2aSPI_WriteAndRead(handle, 3, buf)
assert (packet3 ^ ord(buf[2])) & 0xFF == 0 # 0x13 reads back as 0xDE

## [when done, close session]
u2adll.u2aClose(handle)

Regards,

Derek Payne

Hi Danilo,

here is an example .tcs configuration, you should get a sawtooth ramp after clicking the Ramp Enable checkbox. 

e2e2492.tcs

Please study the operation from datasheet and EVM user's guide. Please also read the LMX2491 datasheet and user's guide, we have added more examples in there.