LMX2582: MUXOUT / SDO timing
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?
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) = 0 immediately before readback, does readback work?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Derek Payne:
This is what I do:
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?
After resetting the chip in step 2, the default register values are loaded. The default value for R0 is lock detect, rather than readback. So you need to send another write to set the readback register.
Here's what I would do:
I'm not sure what values are present in the device at startup. After POR but before soft-reset using R0, 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 is guaranteed to load the defaults in datasheet 7.6.1 for all registers.
Re-enable readback: 0x00 0x00 0x04
Re-enable readback: 0x00 0x00 0x04
Looking at the datasheet 184.108.40.206 the value for MUXout as readback is not R0 == 1, but R0 == 0. Can you confirm, please?
Nevertheless, it sounds sane to expect that the defaults are set up after POR or reset. Looking at the 220.127.116.11 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 bit setting for readout).
You are correct, R0 == 0 for readback. Step 2 should just be write 0x00 0x00 0x00, or any other register write that satisfies R0 == 0 to enable readback and R0 == 0 to prevent reset. Sorry for the confusion.
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.
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.
In reply to Hao Z:
Did this solve your problem?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.