• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 47 subscribers
  • Views 821 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.

ADS131A04EVM: Startup procedure

Xavier de Bellabre
Prodigy 580 points
Part Number: ADS131A04EVM
Other Parts Discussed in Thread: ADS131A04

Hello,

I am supporting a customer who is using the ADS131A04EVM to interface it with an FPGA and has some issues with the startup procedure.

In the capture below he is attempting to follow that procedure (listed in page 79 of the ADS131A04 datasheet) and makes the following observations:

  • He sees the ready status
  • He sends the unlock command
  • He sees the unlock command was received in the status word of the next write
  • However, after that, all config writes only get back the unlock status word on the DOUT line
  • He also sees a little pulse on the DOUT line on the next command frame start

The clock period used was of 320ns and the channels visible in the capture below are as follows:

  • Chan 0 – miso (DOUT)
  • Chan 2 – clock
  • Chan 1 – mosi(IDN)
  • Chan 3 – cs

The steps that were followed are the following (DIN = falling edge, DOUT = rising edge):

  1. Send Unlock command – 0x065500
  2. Write to A_SYS_CFG register – 0x4BE800
  3. Write to ADC_ENA register – 0x0F0F00
  4. Send Wakeup command – 0x003300
  5. Send Lock command – 0x055500

In terms of hardware, he has an FPGA eval board connected to the SPI header of the ADS131A04EVM, with mosi and miso (per silkscreen issue) swapped and the evm digital side spi traces cut to isolate for external use only. The jumper settings on the EVM are as follows:

  • M0 – IOVDD
  • M1 – GND
  • M2 - GND
  • S4 – down (manual)
  • S5 – up (header)
  • S8 – up (header)
  • S7 – down (slave)
  • JP8 – uninstalled
  • JP9 – installed
  • JP10 – uninstalled

Any idea why the second step isn't working and why DOUT repeatedly shows the unlock status word after a quick pulse?

Thanks.

  • 0 in reply to Xavier de Bellabre
    TI__Guru* 97975 points
    Roger,


    I'm not sure what the problem is. It is possible that the device is continues to return the UNLOCK because it is not interpreting the communication after the first command. I believe that the device is supposed to respond with the 16 bits with the last received command.

    To test this communication, I would try something a little different. For the first command after the UNLOCK, send the null command to verify the UNLOCK was received (I understand that you can see that it is already but I'd like it separated out) Then try sending a read for the A_SYS_CFG register instead of a write and see if the register read comes back as the default 60h. After you are able to read from the register, then try writing to it.

    Also, the SCLKs look like a continuous set of SCLKs. Can the 24 bit words sent to the device be separated a bit more in time? I can't see the timing for /CS to SCLK to verify the separation from the edges of /CS to either edge of SCLK. However, adding some time between the /CS communication might help.

    I'm not sure about the extra little DOUT pulses. However, as /CS goes high, the DOUT will be Hi-Z. If there isn't a good pull-up , this might be a slow transition. Also, it looks like the logic analyzer used here is a Saleae. I do have one of these analyzers with the software. If the file isn't too large, it can be posted here and I can look at it.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 30 points

    I Attached the Salae file..... I'll try the suggested null then read today to check the responses.. I had to change file name extension form .logicdat to .txt for site to allow it, nto sure if that works when you change it back.

    Fullscreen ads131a04_setup_capture.txt Download 
    

Data save2Te�ʚ;����~�d�����~�d�����~�d�����~�d�����~�d����2�h*��~�d�����	Channel 0�?�?�~�d�����E�	Channel 1�?�?�~�d������	Channel 2�?�~�d�������	Channel 3�?TTTT0���*�����Tʚ;���TT�~�d�������TTTTTe��~�d����T�T0��sG+����;			�	�����000 ���Ā @�@�����������K!?�A������������!@�@������������!@�@�����������}��*������������*��+�
	a+��+��"+�E(+�U(+�V2+�$#�7+�$�7+�%�A+�/.0��QA+����;%%%>�B�����������B��B�������
~����>�B>���������������������*�����������*�	+�
	�+��<+�0���F+�_��;����Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q��Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q��Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�Q�����*�����������*���*�
	�*�2+�R+�('�+�.r+�/�+�98�+�CB�+�ML�+�WV!+�]+�^2+�hgR+�rqr!+�|{�$+����'+����*+����-+���1+���24+���R7+���r:+����=+����@+����C+���0��RF+����;			Q����������cY�Aǵ����������*��~�d�����~�d�����~�d�����~�d�����~�d�����~�d�����~�d�����~�d�����~�d����e�SPI�22 serialization::archive 10 17 SaleaeSpiAnalyzer 0 21 13169055061981822594 1 1 13169055061981822594 0 1 13169055061981822594 2 1 13169055061981822594 3 1 0 24 0 1 0SPI#T�~�d�����?T)TTiming Marker PairA1A2TT

  • 0 in reply to michael carter
    TI__Guru* 97975 points

    Michael,

    I was able to open the Saleae file and this is what I found:

    You'll note that the read back of the UNLOCK command is shifted by a bit. I think the problem comes in here at the fall of /CS to the rise of SCLK:

    There is a timing violation for td(CSSC). Here it looks like it's about 2ns, but the spec in the datasheet should be 16ns. I think you'll need to add more delay.

    Also, there is something weird about DOUT. Maybe there's some delay, but I noticed this:

    Regardless check the on the first delay and see if that clears up at least the write to the device.


    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 30 points

    Progress, not sure what is going on with the middle two responses on the write reg commands, checking into that now,, but here is the capture.

    Fullscreen ads131a04_setup_capture2.txt Download 
    

Data save2Te�ʚ;����~�d�����~�d�����~�d�����~�d�����~�d������B��~�d�����	Channel 0�?�?�~�d�����E�	Channel 1�?�?�~�d������	Channel 2�?�~�d�������	Channel 3�?TTTTg��W��!��Tʚ;���TT�~�d����������TTTTTe��~�d����T��Tg���Y���X�;�̑ʋ�����### ��� @�@������������A������ ����tA�����@��[	A@�@@���\�����������\�pg��g��q�
pw�
�w�f�����
]�����g������S^�;%%%>�B��������������B�������R
~��~�2>�B>�	�����������������[���������[�h�
	O�O��g������Y�;����Q�R�Q�R�R�Q�Q�R�R�Q�R�Q�R�Q�R�Q�Q�Q�Q�Q�Q�Q�Q��R�Q�Q�Q�Q�P�Q�Q�Q�Q�Q�R�P�Q�P�Q�P�P�P�Q�P�P�Q��P�P�P�R�Q�P�Q�P�Q�P�P�Q�Q�P�P�Q�P�P�P�P�P�P�P��P�P�P�P�P�P�P�P�P�P�P�P�P�Q�P�P�P�P�P�P�P�P�P��P�P�P�P�Q�P�Q�P�Q�P�P�P�Q�P�P�P�P�P�P�P�P�P�P�P�AA@@�W����������W�[�
	.^�Oa�nd�('�f�.�g�/�j�98n�CB>q�ML^t�WV�v�]�w�^�z�hg~�rq.��|{N����~�������ފ������������>����n�������Ϛ�����������.����g������QY�;			P��Q��Q��R��RO�.dO������������W��~�d�����~�d�����~�d�����~�d�����~�d�����~�d�����~�d�����~�d�����~�d����e�SPI�22 serialization::archive 10 17 SaleaeSpiAnalyzer 0 21 13169055061981822594 1 1 13169055061981822594 0 1 13169055061981822594 2 1 13169055061981822594 3 1 0 24 0 1 0SPI#T�~�d�����?T)TTiming Marker PairA1A2TT

  • 0 in reply to michael carter
    TI__Guru* 97975 points

    Michael,

    I don't see any issues in the timing from the last plot. I did pull out the Saleae file, and this is what the plot looked like:

    For a closeup of the second and third frames, you can see it better in the shot below. The second frame repeats the previous command, but the third frame shifts one of the bits in the communication:

    Frame four comes back with an unusual response, but frame five correctly repeats the command from frame four:

    At this point, I'd get an oscilloscope to see if there are any problems with noise from SCLK. Perhaps there are clocks being lost and added from noise. Additionally, there's still some unusual noise from DOUT as the /CS goes low. Using an oscilloscope, you'll be able to see that the SPI lines are clean, without errors, and with the Saleae, you might be to low in resolution to view any problems.

    One last question, what is the master clock rate that you are using for the device?

    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 30 points

    So i am using the EVM board which has the 16Mhz master clock.  I looked at the signals with the oscilloscope and they look good, i also looked at the signals inside the FPGA real-time capture tool and i get the same as the salea... I added NULL commands in between each command.. you can see it does think there is an extra clock on my second command as it is returning a read response and interesting also is that my enable ADC command of 0x0F0F00, get a response of command not valid and then the next command works for the lock.  I will look at trying to clean up the signals since i am going from eval board to eval board but if anything stands out from this capture let me know.ads131a04_setup_capture3.txt

  • 0 in reply to michael carter
    TI__Guru* 97975 points

    Michael,



    I had a chance to ask one of the digital engineers about this device, and there were a couple of things that I didn't catch in the datasheet. I'll go through your file, and explain what I see. Here is the output of the file that you sent:



    First, it looks like the start is correct. The 065500 unlocks correctly. The master sends a null command and the device repeats the unlock.

    After the unlock command, the device gives the status word as a response, which is 22, indicating an SPI error and a data ready error. I'm not completely sure where these errors come from. It may depend on what has happened previous to these frames, or there may be something else if this is the first communication after power-up.

    During read back after the null command is the first write of the register as 4B6800. I had thought that the device responds back with the same, but actually the device responds back as if this were a read of the register. Therefore, the response of 2B6800 is correct.

    For the next command, I believe that you want to write to the register to enable the ADCs. To do this, you want to write 0F to the 0F register. I believe this command should be 4F0F00 instead of the 0F0F that you send. The response that the device gives is 224000. I'm not entirely sure about the 4000, but the 22 is the response with the status byte. One thing that I wasn't sure about was that an undefined command would respond with the status register.

    Hopefully this is some help to you. Let me know if you get any further.


    Joseph Wu

  • 0 in reply to Joseph Wu
    TI__Guru* 97975 points
    Michael,


    I was checking to see if you've resolved the communication with the ADS131A04. As I mentioned in the last post, it looks like the device is responding correctly to the communication. The device response to a write appears as a read command in the following frame.

    I'll close this post for now, but if you continue to have problems with the SPI communications, post back and it will re-open the post.


    Joseph Wu