AD2S1210 unable to clear errors (Lot and DOS pins stay low)

Steve,

Couple of quick questions/points after briefly looking at your code.

1) Are you communicating with the AD2S1210 in 16-bit transfers and perhaps more importantly could you make this 8-bit transfers?   The reason I ask is that the SPI for this part operates in full duplex mode on 8-bit transfers.  Thus is you are writing two bytes at a time you can't simply put padding 0's or 1's in the bits you don't use as these then will be (or at least the part will try) to write in or read those bits.

2) Why do you have 3 byte wide fault registers and how are they set?  Not clear to me what I'm looking at from your code.

3) A FAULT register clear will only work if the Fault register is addressed during the sequence.   Thus you need to have had communications and to read the value during the sequence for the clear to work.  Note that the Fault register will not be cleared otherwise and that those faults which are sticky/latched will remain set until cleared.

4) Can you clarify how you are reading UVStatus and OVStatus as it does not appear that LOT and DOS are connected to the processor from your schematic but maybe I misread it.

5) Your inputs do appear to be within spec, but during startup it is possible to get false indications in the fault register until the loop stabilizes.

6)  Please also note that any time you issue a hard or soft reset that you need to wait ttrack before the loop stabilizes and the results can be trusted.

Let's look at getting the fault clear working before we proceed further.

Sean

Hi Sean,

Thanks for getting back.

Some initial answers to your questions:

1) in configure mode I'm using 8 bit transfers only switching to 16 bit transfers during normal mode. The FIFO registers in the TI chip are 16bit so only the 8MSB's are actually read out and the others are discarded so when you see SPI_writeDataBlockingFIFO(SPIC_BASE,0x8900) for example, only 0x89 is actually sent out. The bit that gives me confidence this is working is that the line setting up the excitation frequency from the default of 10kHz to 4kHz works perfectly every time....

2) Are you referring to the array of fault registers? so I was unsure as to what the staus of the faults was during the reset sequence so I stored the "read2 values from the three times I read it in.

The  first line: SPI_writeDataBlockingFIFO(SPIC_BASE,0xFF00);            // write to fault register - reads back previous data  reads in the old data (as per your timing diagram) 

(I need to send something out to get the SPI to read a value in)

spi_error[0] = SPI_readDataBlockingFIFO(SPIC_BASE);    //transfer old fault data transfers that value to spi_error[0] all 16 bits of the fifo so the error bits are just the 8 LSB's of that.

This process is repeated during and after the two sample sequences for spi_error[1] and spi_error[1]

What I see is the old data from the previous instruction in spi_error[0] and the same error data in spi_error[1] and [2].

I don't anticipate leaving the code like this, but was trying to see what was going on.

3) I thought that was what the second SPI_writeDataBlockingFIFO(SPIC_BASE,0xFF00) was doing?

Specifically the lines: set the sample low and back, read the fault register and then repeat the sample low and back again.. Have I got this worng?

GPIO_writePin(33, 0); // Pulse SAMPLE/ low
DEVICE_DELAY_US(1); // This guarantees the above 620ns delay requirement
GPIO_writePin(33, 1); // set SAMPLE/ high

SPI_resetRxFIFO(SPIC_BASE); //clear any data from the fifo

DEVICE_DELAY_US(5); // Delay 5us to allow data to transfer

SPI_writeDataBlockingFIFO(SPIC_BASE,0xFF00); // write to error register to read back fault values
DEVICE_DELAY_US(5);
spi_error[1] = SPI_readDataBlockingFIFO(SPIC_BASE); // transfer fault data

//reset errors with second sample

GPIO_writePin(33, 0); // Pulse SAMPLE/ low

DEVICE_DELAY_US(1); // This guarantees the above 620ns delay requirement

GPIO_writePin(33, 1); // set SAMPLE/ high
//GpioDataRegs.GPBSET.bit.GPIO33 = 1; // Set SAMPLE = 1

4) UVStatus and OV status are other parts of my circuit (3.3V OV and UV), if both are 1, the 3V3 is in range. The UV status is used to drive the /reset line during power up as per the scope trace. The LOT and DOS pins are not read in but are taken to test points on the circuit. So I can only monitor those with a scope.

5) Acknowledged, that was my understanding too. 

Hope that clarifies things for you?

Hello Sean,

A bit more info on this issue:

I have now tried three different PCB's (one with the ASTZ part and two with the BSTZ psrt). The circuit is the same in all three, but the ASTZ circuit is on a different PCB layout from a previous project which has been around for some years. All three boards exhibit the same behaviour with my code. To the best of my knowledge no one has looked at this in detail before, so there could be a common hardware issue that we have overlooked.

With adjusting the sin/cos mismatch threshold (0x8A from 0x20 to 0x76 I can clear the fault D4 you see in the above screen grabs, my fault register now reads 11000000 instead of 11010000.

From my understanding the D7 fault is caused by the sin or cos clipping, so should be a hardware  issue. From my measurements this is just not happening during normal operation and to ensure I'm not just on the margin of detection, I reduced the value of the burden resistors R81 and R88 from 9k1 to 8k2 which means my sin/cos  pk-pk is now around 3.8V, so well within the range and is held around 2.5V DC by the bias resistors R78, 82, 89 & 87 . Power supplies are at 5V so I really don't see how this error is being generated, or maybe I'm still not clearing it correctly? I'm not sure I can progress much further with this at the moment without some ideas....

I have tried various values in the 0x88 LOS threshold but so far no sign of losing error bit D6. Otherwise it all works fine...... Are there any pins not connected or other silly hardware things we might have missed on our circuit that could cause this?

Any thoughts?

Steve

Sean,

At long last I have something working wrt clearing errors on this pesky chip. It seems that two steps might be the key to success:

1) Do the soft reset on the chip and wait a while (60ms or so) before fiddling with the config parameters, this was proposed as a solution by one of your previous correspondents

2) When trying to reset the errors, select the configure parameter 0xFF before the reset procedure and then do the reads with 0x7F . I'm assuming that if I send an 0xFF to read subsequent messages during the reset procedure it confuses the device. This step is not clear in the datasheet for the serial comms as it just seems to suggest you can send the next parameter to read the previous data and so on and doesn't seem to indicate that resending the same parameter might confuse the thing, at least that seems to be what's happening. 

It does actually reset LOT and DOS pins now.

One question, does the chip "remember" previous error states during power down?

regards

Steve

So waiting until the TTrack timeout completes makes sense otherwise you run the risk of the faults reasserting.....and to answer a previous question yes certain of the faults are sticky and will remained set until cleared. 

You should be able to write to the same address, e.g. 0xFF repeatedly and that should clear the fault register.  Can you confirm what CPHA and CPOL are for the interface.  It may be that the configuration you have is marginal with respect to timing and thus the ADDRESS isn't read correctly.  Not sure why shifting out 0x7F would then make a difference but it's worth taking a closer look at the timing with respect to what is called out in the datasheet before progressing.

Please take a screen cap of what you see on the scope with WR\, SCLK and DIN so we can verify the timing.   I just want to make sure we can make sense of what is going on before you go much further and run into additional issues.

Sean