Post Go back to editing

AD7381-4: Changes in the configuration register shows no effect / soft reset resets register

Category: Hardware
Product Number: AD7381-4

I am using the AD7381-4  ADC with a STM32F4 microcontroller. The end goal is, to use quad SPI to get all the data I need.

At the moment, I try to communicate with the ADC using SPI only.

I am able the read and write the configuration register.

But it seems, that the changes I've made in the configuration register show no effect.

Here are some measurement I've done on the data lines:

Channel 0 is the CS line

Channel 1 is the SPI clock (SCLK)

Channel 3 is the MOSI line (SDI)

Channel 2 is the the MISO line (SDOA)

Channel 4 is the SDOB line

Hard reset and config register read.

Write to the register (enable 1-wire conversion in configuration register 2).  Reread the configuration register.

Initiate a soft reset. A nop command was send beforehand.

register read after soft reset. As you can see, the register have been reset.

Finally. Reading the ADC value.

As you can see in my measurement, I still get data on both SPI lines (as 2-wire conversion is the default value) after changing to 1-wire only.

I've tried to do a software soft reset, to see if that helps. But the soft reset also resets all the registers (according to the datasheet it shouldn't).

 I also tried to change the baudrate but with no different outcome.

Any pointer in the right direction is apprichiated.


  • Hi,

    We will look into this. I will contact the product owner and get back to you.

  • Hi,

    Sorry to bother, I am also developing this chip and can not even read and write the registers correctly. Could you please share your experience with me?

    My understanding after reading the datasheet is that, the SPI mode can be 2 or 3, a read or write command is always 16 bit, a read command should be followed by another NOP to get the actual data. To read the ADC conversion result, simply keep sending NOPs. Are these correct?

    Thank you in advance!

  • Hi Eeteler,

           Apologize for late reply. When a write to register and the device does not reflect the value written, I normally double check on the timing. But in your case writing to register seems working fine as you mentioned the reset function is enabled when writing to do Reset. I saw that you wrote 0xA300. Can you try writing 0xA100 instead. 



  • Hi nukoligy,

           I had this experience, and I can see the importance of proper timing. In figure 2 of the AD7381-4 datasheet, there is SDI set up time and hold time that is reference to SCLK falling edge. These two parameters are requirement when writing to the device registers. Set up time would say that to make sure the data is set up 4ns prior to SCLK falling edge and then also the same data must be hold for 4ns after the SCLK falling edge to be read by the AD7381-4 properly. This is the timing that normally double check. 

         Reading conversion requires, SCLK and CS signal. A falling edge of the CS releases the SDO lines from tristate and conversion data of the previous conversion is clocked-out and at the same time this also initiate a new conversion in which the data will be clocked-out in the next CS falling edge. The MSB data is clocked-out on CS falling edge and the subsequent LSBs are clocked-out on SCLK falling edges. I would recommend reading the data on the microcontroller on the SCLK wring edge, to make sure data has settled correctly.



  • Hi Jonathan

    Thanks for the reply.

    I turned out it was some sort of chip issue. I built  a second board with the same firmware and it worked fine.

    I don't know where this comes from, but ESD-damage seems the most likely.


  • Hi Jonathan,

    Thank you very much for sharing!

    I have another question about the reading:

    since reading conversion or register data requires 2 SPI transfers, is there any other special rule that these 2 transfers should obey (for example, minimum or maximum time interval between them) ? Currently, although I can establish SPI transfer with the chip, but the data received is only 0000 or some random code.



  • Good to know it is now resolved. Too bad it got damaged.