• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 21 subscribers
  • Views 561 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TICSPRO-SW: Incorrect R1 address in hex export and raw register view for LMX2485E

Andreas Gluck
Prodigy 40 points
Part Number: TICSPRO-SW
Other Parts Discussed in Thread: LMX2485E, USB2ANY

Hi,

During an automation development using USB2ANY and programming LMX2485E both through TICSPRO (v1.7.4.0) as well as via the SDK 2.8 for USB2ANY we discovered that the CTL bits of the R1 register appears to be incorrect (and not always the same!).

Using TICSPRO the LMX2485E is programmed correctly, however when looking at 'Raw Registers', you can see bit 1 through 3 (C1-C3) are often incorrect (we have seen 100 and 111, instead of the correct 001). The same is the case if one exports the hex register values, which I assume is based on the raw register values. Typically not a problem when using TICSPRO, but we used the hex export file in the USB2ANY SDK for automation, at noted the LMX did not program directly. After verifying the waveforms and timing on the microwire interface, it was discovered the R1 CTL bits were incorrect in the hex file. Once corrected, the SDK automation works fine.

Side note, we need to align our TICSPRO version with the 2.8 SDK, so we can use the same firmware version in our USB2ANY. Can you please provide a link (I think 1.7.4.1 uses USB2ANY FW v 2.8.x?) ?

Attached is the data sheet and the TICSPRO Raw Register values.

  • 0
    TI__Mastermind 33840 points

    Andreas,

    I'm not sure what action you're taking that's causing the register to change values? It would be helpful to know.

    I think we need to configure CTL[3:0] as address bits so that they cannot be changed by the application, and that should solve the issue. There's a quick workaround for this change: in C:\ProgramData\Texas Instruments\TICS Pro\Configurations\Devices\PLL\LMX2485E\LMX2485E.ini, in the [SETUP] section, you can set the key CONTROL_LENGTH=4 instead of 1 and this should freeze CTL[3:0] instead of just CTL[0]. I think this should prevent the problem from occurring in the future. I'll also prepare this change for release in the next version of TICS Pro.

    TICS Pro releases with USB2ANY 2.7.0.0 for versions prior to v1.7.5.0. v1.7.5.0 and subsequent releases needed a change to the USB2ANY DLL, and actually use an internally incremented release of USB2ANY 2.9.1.1 that includes some minor changes to SPI chip select handling to allow for about 12x to 16x SPI speedup (allow chip select toggles every three or every four bytes). In theory you should be able to copy USB2ANY.dll v2.8.2.0 directly into the C:\Program Files (x86)\Texas Instruments\TICS Pro folder, replacing the existing USB2ANY.dll, and TICS Pro should just work with the new DLL without errors. That said, I've never tried this, and for TICS Pro versions >= v1.7.5.0 you will be stuck with slow SPI (not really an issue for LMX2485E, but other newer devices will be slow).

    Regards,

    Derek Payne

  • 0 in reply to Derek Payne
    Prodigy 40 points

    Hi Derek,

    Thank you for your response, I will look into your approach. My one concern in increasing CTL to 4 bits is the special case of R0 which only has one bit of CTL (CTL0=0), and CTL1-3 is a part of the data bits. So not sure if that can work in that case?

    As far as the USB2ANY FW releases, we'll try the various dlls and see how that can work to resolve our issues with TICSPRO and SDK.

  • 0 in reply to Andreas Gluck
    TI__Mastermind 33840 points

    Andreas,

    Good point, R0 does behave differently. I can probably come up with an alternate workaround for this device and any others which have the same behaviors, but depending on how many devices behave like LMX2485E I may want to make the fix in TICS Pro core code instead of in profile code... let me look over this for a few days and I'll get back to you Tuesday.

    Regards,

    Derek Payne

  • 0 in reply to Andreas Gluck
    TI__Mastermind 33840 points

    Andreas,

    I figured out what's happening (and it took longer than I expected).

    TICS Pro defines a control length and a control offset for each register, which constitutes the number of address bits and the position of the LSB of the address bits. These fields are used in the import register map function to generate the address of readback for each row in the hex register file, by looking at the hex data. LMX2485E defines only one control bit, because the three address bits are only present on some (but not all) registers. Consequently, the device interprets every register after R0 as having that one control bit set, hence it redirects all the register writes to R1. In fact, none of R2-R7 are actually being updated.

    This requires a fix to TICS Pro core code, and cannot be addressed with just a profile update. The corrections will be included in the next revision of TICS Pro, which if all goes well should go up on the web early next week. I'll keep the thread open until the update goes live.

  • 0 in reply to Derek Payne
    TI__Mastermind 33840 points

    Andreas,

    The new version of TICS Pro is available with the fix for this device integrated. https://www.ti.com/tool/TICSPRO-SW 

    Regards,

    Derek Payne

  • 0 in reply to Derek Payne
    Prodigy 40 points

    Thanks Derek! I will give it a test drive.