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.

  • TI Thinks Resolved

LMX2582: Can not read data from MUXout

Prodigy 50 points

Replies: 9

Views: 302

Part Number: LMX2582

I can not read any bits from the MUXout over SPI interface. I can set the register R0 to power up and power down the chip and observe the change in the current draw hence I conclude that the SDI, CSB and SCK are OK.

I'm using LMX2582EVM board connected to a third party module capable of SPI communication through test pads, and a picoscope to monitor the lines.

Here the power up command:

And this is reading register R7:

Any ideas what might be wrong?

  • Hi Hinko,

    Are you resetting the chip at some point before readback? The default for MUXOUT_SEL is lock detect indication. If you try programming MUXOUT_SEL (R0[2]) = 0 immediately before readback, does readback work?

    Regards,

    Derek Payne

    Texas Instruments

  • In reply to Derek Payne:

    Hi Derek!

    This is what I do:

    1. power up the chip by sending 0x00 0x00 0x00 bytes,
    2. init the chip by sending 0x00 0x00 0x02
    3. try to read register R7 by sending 0x87 0x0a 0x0a (I understand that 0x0a could be any other bytes as well)
    4. at this point the scope always shows data 0xFF 0xFF, while I would expect data to be 0x28 0xB2

    I failed to mention in the opening post that I de-soldered R40 from LMX2582EVM board to have LED disconnected from the MUXout line.

    FYI, my scope is attached to the MUXout_TP test point.

  • In reply to hinko kocevar:

    BTW, are the default values as seen in the datasheet 7.6.1 chapter present in the chip after reset/boot up? Or does one need to actually input those value into the chip to read something sensible back?

  • In reply to hinko kocevar:

    Hi Hinko,

    After resetting the chip in step 2, the default register values are loaded. The default value for R0[2] is lock detect, rather than readback. So you need to send another write to set the readback register.

    Here's what I would do:

    1. Reset: 0x00 0x00 0x02 (technically you don't need to power up the chip, it starts powered up)
    2. Re-enable readback: 0x00 0x00 0x04
    3. Test read: 0x87 0x?? 0x??

    I'm not sure what values are present in the device at startup. After POR but before soft-reset using R0[1], many functional blocks inside the device are uninitialized and therefore unresponsive. The device needs to be reset to start the internal state machine initialization sequence. And since readback is disabled before reset anyway, the register contents at startup basically don't matter. However, soft-reset using R0[1] is guaranteed to load the defaults in datasheet 7.6.1 for all registers.

    Regards,

    Derek Payne

    Texas Instruments

  • In reply to Derek Payne:

    Hi Derek,

    Derek Payne

    Re-enable readback: 0x00 0x00 0x04

    Looking at the datasheet 7.6.1.1 the value for MUXout as readback is not R0[2] == 1, but R0[2] == 0. Can you confirm, please?

    Nevertheless, it sounds sane to expect that the defaults are set up after POR or reset. Looking at the 7.6.1.1 I can see that after reset the R0 should be 0x00 0x22 0x1C meaning that readback is not enabled, as you stated.

    I'll try to obtain R7 value as you described above (as soon as we confirm R0[2] bit setting for readout).

  • In reply to hinko kocevar:

    Hinko,

    You are correct, R0[2] == 0 for readback. Step 2 should just be write 0x00 0x00 0x00, or any other register write that satisfies R0[2] == 0 to enable readback and R0[1] == 0 to prevent reset. Sorry for the confusion.

    Regards,

    Derek Payne

    Texas Instruments

  • In reply to Derek Payne:

    Thanks for confirming Derek!

    In the meantime I've been testing different settings on my hardware that does SPI communication. Especially changing the CPOL/CPHA parameters that affect sampling and clocking of the MISO/MOSI lines.

    By using CPHA=1 I can get some bits sampled on the MUXout line, but the data is not correct. This makes me think that the SPI protocol with CPOL=0 and CPHA=0 is not suitable for data readout from LMX2582.

    I manages to get some clarity on the differences between uWire (Microwire) and SPI protocols. As they are pretty similar in wiring and functionality (in fact uWire is considered a subset of SPI according to wikipedia), they do differ in one major aspect: when the sampling of the MISO (in our case MUXout) line is preformed. On page 5 of one can clearly tell that master on uWire protocol reads/samples on the rising edge, same as writing data. On the other hand SPI, always uses opposite clock edges.

    That being said, I will try to bitbang the whole communication with the cheap FTDI hardware or RPi I have at hand to see if I can read MUXout as expected! Sadly, I do not have the ability to change our designated  hardware that is only capable of doing SPI (and not uWire) so I can only get so far with this bitbang approach.

  • In reply to hinko kocevar:

    Hi Hinko,

    I believe that LMX2582 has similar timing behaviors with LMX2594. We just revised the datasheet of LMX2594 to clarify the timing requirements.

    The LMX2594 supports either CPHA = 0, CPOL = 0 or CPHA = 1, CPOL = 1. The MUXout data is clocked out after the falling edge of clock. For details please refer to Figure 1 and Figure 2 of LMX2594 datasheet as well as the notes under them.

    Regards,

    Hao

  • In reply to Hao Z:

    Hello Hinko,

    Did this solve your problem?

    Regards,

    Hao

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.