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.

ADS131A04: On power up, issue reset command, does not return 0xff04 as documented

Part Number: ADS131A04
Other Parts Discussed in Thread: ADS131A02

I am implementing an interface to the ADS131A04. I followed the startup sequence in ads131a02 ADC.pdf, page79. My RESET pin is tied high so it goes high on power up. I am sending a soft RESET command as my first command then reading status until I get the status of 0xff04. Initially this worked.

When I had initial success I followed up by configuring the chip, sending:

        ADC_TxBuff[0] = 0x6b03;        // WREGS: 011a aaaa nnnn nnnn = starting reg = 0x0b, 4+1 registers to write
        ADC_TxBuff[1] = 0xe83e;            // reg 0x0b & 0x0c
        ADC_TxBuff[2] = 0x02a0;            // reg 0x0d & 0x0e
        ADC_TxBuff[3] = 0x0f00;            // reg 0x0f & 0x10
        ADC_TxBuff[4] = 0x0000;
        ADC_TxBuff[5] = calc_CRC(ADC_TxBuff, 10);    // size = size in bytes

Is the configuration persistent after power cycling?

I then enabled ADCs with the command 0x4f0f, woke up the device with command 0x0033, locked registers with command 0x0555 and then read the ADCs once every 23ms using the status command.

Everything looked great...

However, now when I start up my device I never get the 0xff04 status reply. Instead, the status response to the RESET command (0x0011) I get 0x2210. For the followup command I then send a null command (0x0000) I get status response 0x2250. I send another null command (0x0000) I get status response 0x2210. Subsequent status commands return 0x2210.

The spec says that the null command, 0x0000, should return STAT_1 register in the following command. STAT_1 is an 8 bit register. Is STAT_1 the high 8 bits? What is in the lower 8 bits?

I am using 16 bit words, no hamming.

It appears to me that the device just starts up ready and reading. When I request status (0x0000) not only do I get status response but I get four very high values. I don't have actual sensors hooked up to the ADC chip yet so I can believe the very high numbers are probably ADC readings.

Thanks in advance for your assistance.

    ken

  • Ken,


    I'll just answer the first easy questions and then circle back to the reset command issue.

    - The registers are in volatile memory. If you cycle the power, the device will not retain the register contents.

    - I believe the STAT1 bits should be the first 8 bits, the last 8 bits should be 00h.

    There are a couple things that could be happening with the RESET command to not get the proper response. First, I would check to see if the reset actually occurred. If you had written to the registers, I would check to see if the registers returned to the default value. Second, is the device locked? If the device is locked, I think it will only respond to UNLOCK, NULL, RREG, and RREGS, ignoring a RESET.

    One thing that is important is that the RESET occurs at the completion of the data frame. That means that you can't write the command and then short clock the remainder of the frame. You must complete the frame and then the the reset occurs.

    Hopefully that helps. Let me know if you continue to have problems with the device.


    Joseph Wu

  • OK, so it sounds like the device is locked upon power cycle. I’d like to get the device status upon restart so I know if I should unlock it. I don’t see the lock/unlock state in any of the registers. How can I determine the lock/unlock state?

     

    I added an unlock command before the soft reset command and that appears to do the trick.

     

    I locked the device before power cycle. Does the lock/unlock state persist after power cycle? Or does it default to locked state on power up?

     

    As noted earlier, the status response is 0x2210, 0x2250 or 0x2230 at power up. If the first byte, 0x22, is the status register, what is the second byte? It is not 0x00 as you say it should be.

     

            ken

  • I see what's happening: Null command returns 0x2210: the first byte, 0x22, is the command ACK for read Stat1, the second byte is STAT_1 register data.

    I'll do some more checking...

  • Ken,


    I don't know of any particular way to determine if the device is in a locked or unlocked state. You could send it a command that is not LOCK, UNLOCK or a read register and then check the register for a F_OPC flag to see if the command was invalid or ignored.

    I just noticed a section in the datasheet on the UNLOCK command. If you go to 9.5.3.6.1, it looks like the device requires an UNLOCK after a POR or RESET. If there has been a power-cycling, then the device powers up locked.

    I'll need to check on the last byte of the null response. I thought it was 00h because I had some device responses recorded from a previous look at the device. I'll get back to you later on this one.



    Joseph Wu

  • Ken,

    I'll still need to check on this, but I think the null response is 22h and then the STAT1 register. The 22h refers to a RREG of register 02h, which is the STAT1 register.


    Joseph Wu

  • Ken,

    Sorry, I didn't see your previous post. However, I think you're right about the 22h.

    Joseph Wu

  • Ken,

    Just to let you know, I did confirm this. The response for the null command is 22h and then the STAT1 byte. The 22h comes from the equivalent command for read register of 02h.

    Joseph Wu

  • Issue is resolved. If the chip is locked then it will not respond to the RESET command, section 9.5.3.2. Subsequent null commands will return 0x22zz where zz is the contents of the STAT_1 register. If using the soft reset, be sure to unlock the chip using the UNLOCK command, section 9.5.3.6 before issuing the RESET command.

    In section 9.5.3.1 NULL: Null Command:  REG(STAT_1) will be 0x22zz where zz is the contents of the STAT_1 register. I didn't find this clearly stated anywhere in the spec.

        ken