Post Go back to editing

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

Hello,

I've been trying to get to the bottom of a problem with my device. I can get it to read position and speed without problems, but I can't clear the errors no matter how hard I try.

One of the the errors seem to suggest the Resolver feedback might be causing clipping, but I have checked the inoput to the device and it looks within limits.

Here is my circuit:

R81 and R 88 are 9K1, C69 and C66 are 10pF, R78, 82, 89, 87 are 47K and C67, C68, C65 and C70 are 1nF

Looking across R88 the following is to be seen:

Where purple is one side of the EXC waveform (for reference), blue and yellow are the sin+ sin- centred around 2.5 volts and red is the calculated differential input at 4Vpk-pk. I believe this is with operational limits?

The excitation frequency is set at 4kHz. and goes from 10kHz (default) to 4kHz during configuration so is working as it should.

When I run my configuration code the following is what I see:

The blue and yellow are now on the LOT and DOS pins. so they briefly go high and then low again, never to go High again, but the device reads position and speed happily.

If I look at the error data with the default chip configuration values except the resolution and excitation frequency,  it looks like this:

If I try to mess with the configuration values it improves a little but only ends up like this (see my code for the latest values):

I've tried a number of variations of the thresholds (event putting them at max and min and so far have been unable to get this to work. I could really do with some suggestions please.

I've also checked that the hard reset is working correctly:

It seems to hold low for several ms until the 5V is properly established.

Blue is the /reset line and yellow is the 5V supply, purple is the EXC+ output.

I'm using a TMS320F28379D to communicate with the device using an SPI interface at 5MBit at the moment.

The Code can be inspected here:

PDF

I'm hoping someone with better knowledge of the chip can spot where I'm going wrong..... 

regards

Steve

  • 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?

    100Specifically 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