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.

LMX2694EPEVM: Part will not program with USB2ANY and TICSPRO

Part Number: LMX2694EPEVM
Other Parts Discussed in Thread: USB2ANY

I've been programming the LMX2694 fine for a couple weeks using a USB2ANY and TICPRO.  All of the sudden it stopped programming the part. I replaced the USB2ANY with a new one.  I can tell the chip is in some sort of a reset mode because it reads around 281mA.  I measured the SPI lines and noticed that when in idle the SCLK lines and the CS/LE line are both reading high. I removed the USB2ANY from the LMX2694 and measured the lines just from USB2ANY and SCLK and CE/LE are both being held high once I pick the LMX2694 in the TICSPRO tool.  When a SPI function is issued you see the CE/LE line go low and then the SCLK will go low after 600ns or so and then start clocking with the data.   According to the LMX2694 data sheet SCLK must be low when CE/LE goes low or the chip will not program.  I'm not sure if there was an update to the USB2ANY, but it is not issuing the SPI commands properly from TICSPRO.   I used a different microcontroller to try and program the LMX2694 and I was able to load registers. So I know the LMX2694 is working properly.  Need some guidance on this please.

  • First, a piece of trivia: it turns out that, due to the implementation choices for the SPI controller, the LMX2694 does not have any set-in-stone requirement for the clock to be low when the chip-select line is high. While I've personally found it confusing that the TICS Pro profiles are configured to operate the SPI bus in a manner that is inconsistent with the datasheet recommendations, it's never prevented programming and as such it's been a low-priority item to fix. We can try setting this to a different SPI transaction mode as a workaround, but there are other things more likely to be responsible that I'd like to check first.

    Did you change the version of the software at any point, for instance downloading a new copy of TICS Pro, between the time when it worked and the time when it didn't? TICS Pro doesn't have any kind of automatic update or other self-modifying behavior like that, so unless you downloaded a new version of the software, I don't see how the USB2ANY could be successfully programming the device one day and no longer successfully programming the device on the next. If you did update the software, can you tell me what version of TICS Pro you're now using that doesn't work? Check in TICS Pro's Help -> About TICS Pro menu option.

    On the other hand, if nothing changed about the software, my next guess is that a pin is being held in a state that prevents programming. It's a little unclear from your description exactly which pins you measured and what state they were in... to be clear, we define the following two pins:

    • CS# (Chip Select active low): should be high when not communicating; low to start a SPI transaction, high to terminate a SPI transaction
    • CE (Chip Enable): should be high whenever the device is active. Unrelated to SPI communication.

    If at any point you're seeing the CE line low, this could be a cause of issues, since the device is powered down while CE line is low. You may want to double-check the state of J1 on the EVM and ensure that CE pin control is in the expected state; note that if it is controlled via software, you must supply a logic-high signal from TICS Pro, which means the CE pin checkbox in the User Controls page of the device profile must be asserted.

  • TICS Pro V1.7.5.15.  is the current version I'm using. I didn't update this between when it was working and when it stopped working.   The SPI Lines i'm talking about are CS and SCK.  CE is always high which is the part enable. 

    I have O-scope probes connected to the CS and SCLK lines of the USB2ANY.  This way I can monitor their states when I'm issuing a SPI command from TICS-PRO.  (I do not have the LMX2694 hooked up to the USB2ANY, I'm just measuring straight from the USB2ANY pins)

    When the SPI is idle both the CS and SCK lines are reading high.  CS should be high, SCK should be low according to the LMX2694 data sheet that states: 
    The CS# transition from high to low must occur when SCK is low. (on page 9 of the data sheet)

    or rather, the SCK line should be low when CS line is transitioning to a low when a SPI command is issued.   

    When I look at this transaction both the CS and SCK lines are high, a SPI command is issued, and you will see the CS line go low and around 600ns later the SCK line will then go low....a little delay occurs and then I see SCK start transitioning like a clock line should.  

    Hopefully that clears things up about the situation of the chip no longer programming when using the USB2ANY and TICS PRO.  since you say there are no automatic updates i'm not sure what could have occurred then.  I just know i'm using a brand new USB2ANY and it exhibits this behavior which is contrary to the data sheet.   Could it have been a firmware update for the USB2ANY?  I know that once I plug that into the PC and open TICS PRO it asked me to update the firmware for the USB2ANY.  

  • Hi Chris,

    While to demystify this issue may take some time, in the meantime, could you try update your TICS Pro to the latest version? I am using V.1.7.6.2, I tried two USB2ANY, one of those needs firmware update. Both USB2ANY works with my LMX2694 EVM.

  • The only version I see available for download is V1.7.5.15.  Could you do me a favor and measure the CS and SCK lines from your USB2ANY and tell me if the SCK line is low when your CS line goes low when you issue a SPI command.  

  • 1.7.6.2 is an internal build that hasn't made it to the web yet, apologies for the confusion.

    I can guarantee you that as long as TICS Pro is operating as programmed in the current release version, the SCK line is NOT low when the CS line goes low during SPI command issue. This is a historical artifact and a TICS Pro implementation detail with USB2ANY that we never got around to fixing, because as far as we could tell it did not affect communication with any devices. You can think of this as accidentally specifying CPOL=1, CPHA=1 instead of CPOL=0, CPHA=0, with reference to the diagram below.

    By inspection, you should be able to convince yourself that as long as a falling edge of SCK before the first rising edge of SCK has no significance in the SPI state machine (a convention we have typically followed on our devices), there should be no impact on communication substituting CPOL=1, CPHA=1 for CPOL=0, CPHA=0. I know the datasheet is very particular about recommending a CPOL=0, CPHA=0 configuration, but believe me when I say TICS Pro has been ignoring this recommendation since the LMX2694 was released, and it has not yet caused any issues - it's been this way for so long that changing the default SPI config to use CPOL=0, CPHA=0 instead may introduce more risk.

    That said, someone took the time to include this specific recommendation in the datasheet. If you'd like to test whether modifying TICS Pro's behavior to be exactly as specified by the datasheet corrects the communication failures you've encountered, we can certainly try a trivial software modification:

    • Navigate to C:\ProgramData\Texas Instruments\TICS Pro\Configurations\Devices\PLL + VCO\LMX2694
    • Open both LMX2694.ini and LMX2694.tcb (the latter if present)
    • For each file, in the [SETUP] section, find the IFACE key and change its value from SPI to SPI_CLKLOW
    • Repeat this procedure with any .tcs file you may have saved prior to now (i.e. if you clicked File -> Save, the save state file generated by that process) before loading that .tcs file with the above modifications to the LMX2694 profile.
      • Now that you've modified the profile, as long as you don't modify or reinstall TICS Pro, you should be able to save and load new .tcs files without any need to manually modify them. It's just the ones prior to the above modifications you'd need to manually update first.

    Upon opening the LMX2694 profile, you should now see the protocol is set to SPI_CLKLOW, which conforms to CPOL=0, CPHA=0. Test the communication using this new SPI config. If it works now, we'll modify the profile before the next TICS Pro release to match the modifications above (and do something to automatically handle old .tcs files).

  • Thank you, This fixed my issue and i'm now able to program the chip.  

  • Excellent, thanks for letting us know. I'll log this as an official bug in the profile; future releases of TICS Pro will properly follow the LMX2694 datasheet guidance on SPI transactions.