Programming multiple devices with TICs pro

Hello Felipe,

Since these devices interoperate on a SPI bus, it is possible to program them all simultaneously, or to separately address each and program them individually. The default profile for LMX2594 does not expose pin control for any GPIOs beyond those explicitly labeled in the Pins section of the User Controls page. However, modifying the device profile can expose these pins to TICS Pro for control. In the device configurations directory (typically C:\ProgramData\Texas Instruments\TICS Pro\Configurations\Devices\PLL + VCO\LMX2594), there should be an INI file called LMX2594.ini. In this file, there are several sections defined, including a [PINS] section. You can increase the number of pins and add pin definitions corresponding to the USB2ANY GPIO pinouts, as long as the GPIOs do not conflict with the other SPI lines. We also store the last state of the application in LMX2594.tcb in the same directory, which could conflict with the newly-defined pins; delete the .tcb file once the pin definitions are updated in LMX2594.ini, before starting TICS Pro again.

The GPIO pinout is shown in the image below (if you are looking at the USB2ANY connector, the key should be right above pin15 U2A_3V3). 13 GPIOs are exposed, but four of them are reserved for SPI bus transactions (SCK/SIMO/SCS/SOMI) so you are allowed to use any of the other 9 GPIO pins. Note that you cannot repurpose the SCS pin as anything except chip-select. My recommendation for driving 12 devices separately is to attach the GPIOs to a 4:16 demux, and distribute the pre-defined SCS signal. You will also want to buffer the SCK/SIMO signals.

TICS Pro automation currently a mostly-unadvertised capability supported through ActiveX bindings. If your automation mechanism can wrap a 32-bit DLL, you should be able to utilize the ActiveX bindings to set the pins. We have another forum post that somewhat documents the ActiveX API through an excel VBA script, it should be sufficient to catalog and define the API functions. I can't find the forum post, but the excel file (which has all the VBA bindings) is located at /cfs-file/__key/communityserver-discussions-components-files/48/3276.TICSPro-Automation-Example.xlsm

Note that if you want to support readback, this is currently a bit tricky since it relies on an undocumented tri-state capability for the MUXOUT pins. For LMX2594, if you write R1[3] = 0 while MUXOUT_LD_SEL = 0, this tri-states the MUXOUT pin. On startup with 12 devices sharing a SOMI line, all devices should be unlocked so the MUXOUT pin state should always be low; nevertheless, it may be a good idea to add some resistance on each SOMI line, in case of accidents. Every readback transaction would first need to enable the MUXOUT pin on a specific device by setting R1[3] = 1 (all other devices should have R1[3] = 0), and after every set of readback transactions you must set R1[3] = 0 again to tri-state the bus and yield to other devices. At some point we will add this description to the datasheet explicitly.

TICS Pro does not currently have a concept of multiple devices or register sets side-by-side, there is only one set of register states for any given profile. Whenever a field is changed in TICS Pro, the software attempts to write the change out through USB2ANY. If your 12 LMX2594 have different register programming, it will be your responsibility to ensure that TICS Pro always has the correct state loaded in software before beginning communication. My recommendation for devices with different programming is to keep track of the differences in whatever automation mechanism you use, and whenever you must switch devices, set the chip select demux to an invalid address so that changing fields in TICS Pro does not change registers on any devices, pre-load the different values, and then set the address correctly so TICS Pro mirrors the target device registers.

Regards,

Derek Payne