ADS8332 stops EOC operation in Auto channel sel mode

Hi Carlhermann,

Off hand, I am not sure what exactly could be the issue. Could you do me a favor and post your scope pictures and schematic. If you do not want to post your schematic let me know and you can send it to me directly.

I would recommend trying to read back the configuration register once you have having problems with the EOC to see if the part somehow reset to its default values.

Regards,

Tony Calabria

Hi Tony,
first of all I'd like to thank you for responding..  While the best is "not having trouble", the second best is someone taking care of :-)

Well, I attached the scope plots showing the signals, as I used "standard probing" with the reference being connected by these short wires with clips rather those tiny adapters directly at the tip of the probe, the noise is most likely (at least a part of) being caused by the measurement setup. Additionally the noise did not really increase with increasing the DC-Link voltage nor does the ADC immediately stops (it's not the first conversion with DC-Link attached and PWM enabled that stops the ADC. While the issue with the noise not causing immediate failure of operation, the "delay" between enable of PWM and ADC might partly be due to the motor's electrical time constant preventing a zero to 100% current increase within the first PWM cycle...
To complete the picture: If I increase the DC-Link w/o operation of PWM or with operating PWM but w/o motor attached (thus switching phases but no current flow), the ADC seems to continue working (it did not fail within the frist seconds as it did with phase line currents)...

Last but not least I attached a jpg showing the ALTERA SignalTap readback (the levels at the FPGA I/O pins), I'm not 100% sure, that the interface's timing is correct, I tried to get the informations from the datasheet togehter and programmed the timing in the FPGA - so please take a look at the timing as well... (The failure is at Sample "0" with the Counter exceeding the timeout detection threshold...)
I will add the "read back the configuration" and add the result of this asap...

Finally, don't bother me for writing "ADC failing" - this is "the result" I observed, it might be caused by anything, my VHDL coding might be the reason as well... (it's likewise the light at home does not come up when toggling the switch, everyone blames the bulb, but there are many other points of failure why the bulb does not light up)
BTW: I had some other issue years ago with the AD7918 of analog which stopped sending data (likewise it had been sent to sleep mode, which was not the case), the countermeasure was adding a pull-up to SCLK (it worked, while up to now I don't now why...)

Best regards, Carlhermann

Hi Tony,
I added the code lines to read the Configuration Register, once in normal operation (to check the reading) and in case of failure to check the ADC status.

The readback with ADC operation results in CFR content "1100 1111 1111" (which is as configured). As soon as the ADC stops operation of the EOC line, I added one "Read_CFR" operation, coming up with "1111 1111 1111" (what seems to be the default value...).

Best regards, Carlhermann

Permanent Reading of CFR to check readback routine / initial configuration

Reading of CFR

One additional info regarding the schematic - this is lost as the power supply circuit (drawn on another page) is not included:

AVCC = VCCIO = 3.3VDC. In fact VCCIO is the main 3.3VDC power line and AVCC is decoupled by a choke and additional buffer capacitor

VCCIO ---------- L --------  AVCC
                |                    |
             C1                C2
                |                    |
   GND ---------------------- GND

The control signals are all LVTTL type, generated by the Cyclone IV FPGA...

Hi Carlhermann,

Thank you for the pictures and further description of the problem.

First off, correct me if I am wrong but it looks like your SCLK data phase relationship is configured to have the data change on the falling edge to be latched on the rising edge. The data sheet may be a little confusing but in this part, we recommend using the falling edge of SCLK to latch in data while the rising edge is reserved for changing data. Having the polarity and phasing reversed may work in some parts when the SCLK is not set to max speed. Therefore, this may not be the root cause of the problem, but I figured I would mention it.

Have you double checked to see if you could rewrite to the configuration register once you activate the power stage? I am curious to find out if the part is somehow seeing a software or hardware reset setting the configuration register back to its default value or if it is in a mode where it is not responding properly.

-Tony

Hi Tony,
well within the VHDL Code I have programmed the SDI Line to change with the rising edge of the SCLK line. Any delay is therefore caused by interconnection within the FPGA and on the PCB. If you take a look at the scope plots, the SDI line (Channel D) changes with the rising edge of SCLK to ensure the signal being stable for being latched by the ADC on SCLK falling edge (as stated in the Datasheet). As both signals (SCLK and SDI) are generated by the FPGA, within the same finite state machine  there is litte to none delay on the signals on the scope plot.
Additionally the ADC seems to change the data on falling edge of SCLK (SDO line, Channel A), the signal is latched by the FPGA with the suceeding rising edge of CLK. There seems to be more delay by the ADC to identify the falling edge and operation of the SDO line...

My first idea was, that the ADC seems to be resettet by nReset (Pin8), but there is a stable 3.3VDC signal.
Assuming the ADC misinterprets the D[15..12] not as "Read Data" (1101b) but "Write_CFR" (1110b), the following "all ones" on the SDI line would also result in the same reading as for software reset.... There is some time delay between issuing a software reset and ADC restarting operation - does this also effect the "Read CFR" ? If the ADC is internally resetting, would the SDO line (the read access is directly on EOC Line timeout detected, which is 20..25 clock cyles after rising edge EOC) be operated by the ADC that time?

I will try to change the signal on the SDI line from being  all '1' following the CMR "Read Data" to the configuration pattern for the intended operational mode. If there is really a problem that the 1101b is read as 1110b (why so ever) the ADC should at least continue operation... That case I would assume there is some timing failure in the startsequence (relation between nCS, SDI, SDO and SCLK). I tried to implement the timing as shown in the datasheet on Figure 3, with SCLK being high during nCS high. Perhaps you could have a look on this in particular (either on the scope plots or on the SignalTap jpg export).

Best regards,
Carlhermann

Hi,
I changed the code to operate the SDI Line (even if not being observed in case of CMR Read) to continuously "configure" the ADC to auto mode (just to exclude the "all ones" was falsely accepted and thus the readback would be "all ones"....

This in fact did not change anything, thus the ADC seems to be resettet by POR or nRESET for the first four bits seems not to be falsely identified as "Write CMR"...

I just did not tried to restart the ADC everytime the ADC stops operation as this is more or less "academic" as this would significantly reduce the conversion throughput and would thus be no solution at all...

Thus it comes down to either HW problem or perhaps still an issue with the SPI interface. Anyone having a complete bitstream for configuration and operation of the ADC?

Sincerely, Carlhermann

Hi Carlhermann,

Sorry for the delay as I wanted to talk with over with some colleagues to get their ideas before I responded. From you description, I believe it is safe so say that part behaves as if it is getting reset leading to the CFR to be loaded with the default values. The initial idea was that maybe the part was seeing 1110b (write CFR) in bits D15:D12 in place of 1101b (read data). So, as I understand it, you decided to keep the ''don't care'' bits high to avoid the part accidentally seeing a software reset. Doing this did not solve the problem. 

A second theory is that the device is seeing 1111b in bits D15:D12 which would be decoded as a default mode command setting the CFR to the default values, very similar to a reset. To me, this seems more probable as the switching transients shown in the scope plots may be interpreted as more than one clock edge causing the converter to see 1111b as the first four bits.

One test I would recommend to see if these switching transients are the root cause would be to put the device in manual channel select mode and continuously write 0000b for D15:12 to convert over and over from analog input channel 0. The SPI interface is full duplex so as you write 0000b for the first four bits to select analog input channel 0, the SDO will output the converted result without you needing to use the read data command.

Regards,

Tony Calabria

Hi Tony,
I changed the interface as suggested to apply "0000" as CMR D[15:12], followed by "0100 1111 1111" for D[11:0]. Thus the ADC should run in manual channel mode. For I have no access to the /CONVST, the ADC still runs in Auto-Trigger mode. Up to the time, the ADC stops operation, the SDO line from the ADC always reads "000" in the TAG bits (see also attached SignalTap Reading). With missing EOC operation the FPGA reads the CFR and the readback value is "1111 1111 1111", thus something seems to have the ADC resettet... So any other ideas left?  (I hope...)
Do you have some scope plots of configuration / reading the converter in autochannel mode with TAG bits activated I can check my serial interface against? Unfortunately I'm missing a complete timing digram, maybe that is not required when interfacing with DSP and using SPI interface "module" in the compiler. Setting this up in VHDL contrary requires all timing to be programmed...

I'll try to doublecheck if there is something wrong with my SCLK, nCS, SDI, SDO and EOC timing to be sure there is no clock cylce missing or anything else...

Hope to find the solution soon as I'm running out of time,

Best regards,
Carlhermann

Hi,
I modified my signaltap to run with 80MHz sampling - this accomodates the ADC changing the SDO with falling edge of SCLK (as I interpreted the datasheet).
Adding the info, that on CFR readback the first four bits are the data from the latest conversion (which means in my humble opinion the first four falling edges of SCLK), the readback seems to be 111111111110, which is the last Bit being '0', indicating software reset?

I added a picture to clarify this - could you have a look on this and rate it?

Thanks a lot, Carlhermann

Hi Carlhermann,

Thank you for the logic picture. With the resolution increased, I can see it much better than the logic pictures you posed a few replies ago.

One thing that I noticed is that you have the SCLK dwell high. This is fine as long as you understand that the MSB out (SDO) is clocked out 20ns max following a /CS falling edge. The SDO is then transitioned every 15-20ns after (tD2 timing). Meaning that in the picture that you posted, once you bring /CS low, the MSB will be available immediately. Since the clock dwells high, when the converter sees the first SCLK falling edge, the SDO data will change to MSB-1 20ns immediately following. Since you are using the rising edge to read data, the first data that you think is the MSB is actually the MSB-1.

That being said, going back to the logic picture you recently posted -

The way that you inpreprate the data is 0001 1111 1111 1110

but what it really is reading out is 1000 1111 1111 1111.

You mention the readback of the CFR as 1111 1111 1110 which is not possible because the bit 0 RESET bit should always read back as 1.

The proper way to use this device is to use the falling edge of SCLK to read in the data and have the data change on the rising edge of SCLK. The device latches in the SDI bit on the falling edge of SCLK. So, going back to the logic picture that you posted, the first falling edge following the /CS low is going to latch in the MSB on the SDI line.

If you look at the communication lines on an O-scope it may appear that the data is changing on the falling edge, but it is not. It is changing a fixed time period after the falling edge. The reason it is designed this way is so that the hold times, etc. can be met as the SPI SCLK is sped up for customers using faster clocks.

My recommendation as a test is to set the clock polarity so that the SCLK dwells low. Then configure the micro to latch data in on the falling edge of SCLK so that data is changing on the rising edge of SCLK for both the SDI and SDO line.

Regards,

Tony Calabria

Hi Tony,
I changed the timing (see picture below), but this just made a difference in reading back. As the data to the ADC was already changing on rising edge there is no change in FPGA towards ADC signal timing. As expected, there is also no change in operation (still failing). Thus - if you agree that the ADC is constantly set to Channel 0 (by writing CMR "0000") - what could be the event, causing the "reset to default? Does it come down to (whatever) problem on either power line or the nReset (while none of these signals show much noise explaining this behaviour)... Is there any mechanism which could falsely be triggered ending in this beaviour?
Anything left to try, check, record to help in identifying the root cause and to define the measures to keep ADC operation alive?

Best regards, Carlhermann