ADS54J42: Cannot configure the digital pages (6800, 6900 or 6A00)

Hi,

The person who supports this device is out of office for the next couple of days, but from a similar device with a similar symptom I must ask if the sample clock *and* the SYSREF are running and present at the ADC with sufficient amplitude and at the right common mode level.    On a device that I do support I know that I will read back zeros from the paged register space if SYSREF is not running, even if I could still read back from the non-paged registers regardless.  See note 1 in section 7.3 of the datasheet.

Regards,

Richard P.

Thank you.

We have now measured both the reference clock and the sysref clock and they are within spec as far as we can see..
The sysref is DC-coupled so We tried as well to set bit 1 register 53 in master page to '1'.

I cannot even read address 4 in General registers.

I can however read back address 11 in General register so the general register is not completely unreadable...

The following sequence should in the second row read back as (00 00 69) as the register should be readable, but not...
MOSI (40 04 69) -> MISO (00 00 00)
MOSI (C0 04 00) ->MISO (00 00 00)

There are lots of inconsistencies in the datasheet (we have draft 3, revised in january 2017). E.g. in 8.4.1.5 the sequence to select a page is to write to 4003 before 4004 but in the examples, e.g. in 8.5.2, the sequence is re reverse. We have of course tried them both. After power cycling...

Now we have measured the clocks once again.
The reference clock is 400MHz with a swing of about 1.9Vpp, no Common-mode voltage
The SYSREF is 1.25MHz with a swing of about 0.8Vpp with 1.2V Common-mode voltage
The setup time from SYSREF rising edge to falling edge of clk is 600ps
All within spec as far as we interpret the datasheet

We have images and sample values of the measurements if needed

Bjorn,

Make sure the sample clock to the ADC is AC coupled. Is the SYSREF AC or DC coupled in your setup? Make sure to always do a digital reset (0x600001) after writing to any registers in the main digital page for the changes to occur. This bit must be pulsed after power-up or after configuring registers in the main digital page of the JESD bank. Any register bits in the main digital page (6800h) take effect only after this bit is pulsed

Go ahead and write the following commands then try doing a read.

0x000081

0x001180

0x001180

0x005920

0x400468

0x400300

0x60F701

0x600001

0x600000

Regards,

Jim

Tried the sequence above without luck.

Our complete sequence from power-up to read is as follows (in pseudo-code style):
("poke" commands refer to access to physical pins and "write" commands refer to SPI accesses)

First, after logging in to Linux we run a board initialization sequence script:
poke 0x41240000 0 # ADC power down pin set low
poke 0x41220000 7 # ADC reset pin set to high
cg-setup -D /dev/spidev32766.0 # initiate the sample clock and hence the sysref clock as well
sleep 1 # let everything stablelize
poke 0x41200000 1 # set FPGA logic reset
poke 0x41200000 0 # release FPGA logic reset
poke 0x41240000 1 # ADC power down set high
poke 0x41220000 3 # ADC reset pin set to low

After the above script we run a JESD/ADC setup script:
poke 0x41220000 3; delay #
poke 0x41220000 7; delay # ADC reset pin toggle low->high->low with a 200us delay
poke 0x41220000 3; sleep 1 #
write 0x000081; sleep 1
write 0x001180; delay
write 0x001180; delay
write 0x005920; delay
write 0x400468; delay
write 0x400300; delay
write 0x60F701; delay
write 0x600001; delay
write 0x600000; delay
sleep 1
write 0xe0f700; delay
Read output is 0x000000 when expected 0x000001

Bjorn,

Register F7 is a write only register. You will always read a 0x0 for this. Have you tried reading another register that is W/R? If so and you still read an invalid value, is there a chance your FPGA is driving the SPI lines with an incorrect voltage level? Can you send the portion of your schematic that shows the ADC?  What is the frequency of the SPI CLK?

Regards,

Jim

Still no read, i.e. probably no write ether.

I have tried to write to page 6800 address 0xAD whith value 0x03 and I expect to read that value back.

The sequence this time is:

First:
poke 0x41240000 1; sleep 1 # PD power down unset
poke 0x41220000 3; delay #
poke 0x41220000 7; sleep 1 # PD physical reset
poke 0x41220000 3; sleep 1 #
write 0x000081; sleep 1
write 0x001180; delay
write 0x001180; delay
write 0x005920; delay
write 0x400468; delay
write 0x400300; delay
write 0x60F701; delay
write 0x600001; delay
write 0x600000; delay
Then:
write 0x400468; delay
write 0x400300; delay
write 0x60ad03; delay
write 0x600001; delay
write 0x600000; delay
write 0x400468; delay
write 0x400501; delay
write 0x400300; delay
write 0xe0ad00; delay -> replay=0x000000
write 0xf0ad00; delay -> replay=0x000000

Bjorn,

When following your writes and reads shown above, I have no problems reading the registers with our EVM. If I disable the sample clock, I am unable to do reads. Can you send your schematic?

Regards,

Jim

I'll check with our customer. I guess it is OK but they are the design owners and must make the decision.
Do you have a GPG-key or anything I can use to encrypt the schematic while in transit?
I surely cannot put it here in the public anyway :o)

ADS54J40EVM_ADS54J60EVM-SCH_D.pdfBjorn,

We do not have a GPG-key. Can they just send the ADC portion of the schematic? If not, have them take a look at ours to see if they notice anything wrong.

Regards,

Jim

 

Bjorn,

The ESD protection is like +/-1000V. I do not think this is the issue either. Do you know the level of the FPGA SPI signals?

Regards,

Jim

As soon as I know how to email you the schematic of our design I'll send it to you.
We have tried to compair the eval design with our design.
The SPI signalling is 1.8V (connected to an 1.8V FPGA bank configured to be signalling LVCMOS18)

Try to attach a cut out schematic of the ADC.

If you want the entire schematic I need an emal adress or another private way of sharing it with you.

Schema-att-ev-skicka-1.0.0.pdf

An observation:
We see in the datasheet that the clock input is biased internally to 1.15V via 400 Ohm.
Our clock is ac coupled via 100 nF capacitance so we expect to se the clock biased to 1.15V at the terminals of the ADC.
We cannot however se any bias at all when measuring on the terminals.
Is this normal or is it an indication on some problem?
We have measured all power supply pins on the ADC and they are all at the expected voltage.
We feed AVDD3V with 3.3V which is within specifications according to the datasheet, all other are as nominally specified.

Bjorn,

When I measure the ADC clock common mode at the pins of the ADC, I get 1.15V. This may be a problem with your part. Can you remove the caps and see if you get 1.15V at the pins after powering up the device? Also, can you remove R411 and install R414 and verify that the PDN input is at GND? I noticed this is going to the FPGA and may be driven high by accident.

Regards,

Jim

The PDN pin has already been investigated, and changed to pull-down.
I have measured the PD pin during power up to make sure it was down until clocks were in place.

When we remove the caps from the clock circtuit I measure around 38mV bias at the clock input terminals.

We have decided to replace one of our four ADC:s with a new one to rule out systematic damage of any cause.
Circuit delivery is expected on monday and replacement a.s.a.p.

Sweden closes on friday due to midsummer celebrations and I leave for the day now.
Please try to find out as much as possible for me to test, measuer or do during tomorrow and we might find a small window in the afternoon (your morning) to discuss results.

Björn

Bjorn,

I noticed you did not have a 100 Ohm termination resistor for the CLK input. We recommend that this be used as some customers have seen issues when this was not used.

Regards,

Jim

We saw this as well and tried that this morning without any change.

The most probable cause for our problems seam to be the non-existing internal bias of the clock input.
Have you seen any sign of silicon problem regarding the internal biasing? Would the 400Ohm bias resistor break in case of a short circuit to ground?
Is there enything else we can observe to make sure the problems are clock-related?

We have also tried to externally bias the clock pins using 430Ohm to 1.15V, but no change in respons.

5460.SBAS756B_Draft3_01192017.pdfBjorn,

I am checking with the design team regarding this. Is there any way to measure the current draw on the ADC supplies? Are you following the powering up sequence in the revised data sheet I have attached?

Regards,

Jim

We will try to measure the current drawn by the ADC tomorrow.
At least some of the voltages is prepared for current measurement but not all.

We have checked the power-up sequence against the draft 3 datasheet and the only important information seam to be DVDD rise before IOVDD rise and that is OK. There seam to be no other hard requirements regarding ramp up time or sequence.

If you want to review the entire schematic including power supply you are welcome but I need somewhere more private to send it to. I cannot attach our customers full design into the public here at the forum...

SUCCESS!
When measuring the current of the different voltages we realized what was wrong!
The power down pin is named PDN and we interpreted the name as PowerDown active low (N=negative).
That is the usual way we name signals.

The power down however is active HIGH. The result was that we 'release the powerdown' but instead set the circuit in power down state.

We have search the datasheet without finding any reference at all to the polairity of the power down signal.

I suggest you update the pin description with the active polarity of all signals.

Thank you for all your help.
We feel very well taken care of in this support case!

Bjorn,

This is good to hear. We will add more text in the data sheet to make the PDN more clear. For future reference, always take a look at the EVM schematics for how pins such as these are connected.

Regards,

Jim

Absolutely, but in this particular case it did not help as it was the interpretation of the active signal level that was misunderstood and we did look in the evm schematic without catching this missunderstanding.

It is not clear if the pulldown was to inactiavate or activate the device. Also the datasheet describes an internal pull-down of PDN but not the purpose.

We are happy and so is our customer. I'll be back on monday as the midsummer celebration starts here now.

From our point of view this case is now closed and we are satisfied with the help we got from you!

Björn

Hi,

I'm working with Björn on this design. We manage to set up the ADC (we think) and we can control K28.5 and data transmission. But what we get from the ADC is very odd.

We set up the ADC as LMF=421, no decimation. When we start transmission, the link appears to work. No symbol errors, no 8b10b decoding errors. But the ILA data is very strange:

# FPGA JESD lane 0 recorded ILA [byte order in ILA sequence]
0x1c010000 [3,2,1,0]
0x12011700 [7,6,5,4]
0x008000cf [11,10,9,8]
0x0000c500 [xx,xx,13,12]

Expected data would be:

0x03000000 [3,2,1,0]
0x0f011700 [7,6,5,4]
0x0080002f [11,10,9,8]
0x0000xx00 [xx,xx,13,12] (I haven't calculated check sum)

Can we trust the data? And which lane is which? What we think is lane 2 is named lane 28...

Can you explain this? See the sequence below.

Best regards,

Anders

This is the sequence we run (and some status included):

ADC init
DBG (tx outvector) | 00 00 81
DBG (tx outvector) | 00 11 80
DBG (tx outvector) | 00 53 02
DBG (tx outvector) | 00 54 80
DBG (tx outvector) | 00 53 01
DBG (tx outvector) | 00 53 00
DBG (tx outvector) | 00 53 01
DBG (tx outvector) | 00 53 00
DBG (tx outvector) | 00 20 00
DBG (tx outvector) | 00 21 00
DBG (tx outvector) | 00 26 00
DBG (tx outvector) | 00 59 20
DBG (tx outvector) | 00 39 C0
DBG (tx outvector) | 00 3A 40
DBG (tx outvector) | 00 56 04
DBG (tx outvector) | 00 53 42
DBG (tx outvector) | 00 55 00

Start ADC K28.5 pattern, LMF=421
DBG (tx outvector) | 40 03 00
DBG (tx outvector) | 40 05 00
DBG (tx outvector) | 40 04 68
DBG (tx outvector) | 60 F7 01
DBG (tx outvector) | 60 00 01
DBG (tx outvector) | 60 00 00
DBG (tx outvector) | 40 03 00
DBG (tx outvector) | 40 05 00
DBG (tx outvector) | 40 04 69
DBG (tx outvector) | 60 00 80
DBG (tx outvector) | 60 01 C4
DBG (tx outvector) | 60 03 00
DBG (tx outvector) | 60 05 00
DBG (tx outvector) | 60 06 17
DBG (tx outvector) | 60 07 08
DBG (tx outvector) | 40 03 00
DBG (tx outvector) | 40 05 00
DBG (tx outvector) | 40 04 6A
DBG (tx outvector) | 60 16 02
DBG (tx outvector) | 40 03 00
DBG (tx outvector) | 40 05 00
DBG (tx outvector) | 40 04 68
DBG (tx outvector) | 60 00 01
DBG (tx outvector) | 60 00 00
DBG (tx outvector) | 40 03 00
DBG (tx outvector) | 40 05 00
DBG (tx outvector) | 40 04 6A
DBG (tx outvector) | 60 17 40
DBG (tx outvector) | 60 17 00
# FPGA Lane status =
0x00000001 # CGS sync found lane 0
0x00000001 # CGS sync found lane 1
0x00000001 # CGS sync found lane 2
0x00000001 # CGS sync found lane 3

Start ADC data
DBG (tx outvector) | 40 03 00
DBG (tx outvector) | 40 05 00
DBG (tx outvector) | 40 04 69
DBG (tx outvector) | 60 01 44
DBG (tx outvector) | 40 03 00
DBG (tx outvector) | 40 05 00
DBG (tx outvector) | 40 04 68
DBG (tx outvector) | 60 00 01
DBG (tx outvector) | 60 00 00

# FPGA JESD lane 0 recorded ILA [byte order in ILA sequence]
0x1c010000 [3,2,1,0]
0x12011700 [7,6,5,4]
0x008000cf [11,10,9,8]
0x0000c500 [xx,xx,13,12]

# FPGA JESD lane 1 recorded ILA
0x1c000000
0x12011700
0x008000cf
0x0000c600

# FPGA JESD lane 2 recorded ILA
0x1c1c0000
0x12011700
0x008000cf
0x0000c300

# FPGA JESD lane 3 recorded ILA
0x1c020000
0x12011700
0x008000cf
0x0000db00

# FPGA JESD raw data snapshot lane 0-3
0xffffffff # Sample n+1, n (16-bits) lane 0
0x1308e3f3 # Sample n+1, n (16-bits) lane 1
0xffffffff # Sample n+1, n (16-bits) lane 2
0x00eb0413 # Sample n+1, n (16-bits) lane 3

# FPGA lane status =
0x00000007 # Data running, no lane errors lane 0
0x00000007 # Data running, no lane errors lane 1
0x00000007 # Data running, no lane errors lane 2
0x00000007 # Data running, no lane errors lane 3

And this is what the raw 8b10b decoded data look like (lane 3). With K=24 (0x17+1) and F=1, a multiframe is 24 octets, or 6 words:

bcbcbcbc
bcbcbcbc
bcbcbcbc
bcbcbcbc
bcbcbcbc
bcbcbcbc
bcbcbcbc
bcbcbcbc
bcbcbcbc
bcbcbcbc
bcbcbcbc
bcbcbcbc
04e3041c  <- Here is start of ILA sequence, multiframe 1. 0x1c=K28.0
4.04E+07
00e3e3f8
04e3e304
e3e30004
7ce3eb04  <- Here is end multiframe 1. 0x7c=K28.3
00009c1c  <- Here is start of multiframe 2 and ILA config. 0x9c=K28.4, which is ILA config start
17001c01
00cf1201
c5000080
04eb04f8
7c08f8eb  <- Here is end multiframe 2. 0x7c=K28.3
13eb001c  <- Here is start of multiframe 3
080000f8
04e3f0f8
00f8f8e3
8.04E+302
7c000004  <- Here is end of multiframe 3
0800001c  <- Here is start of multiframe 4
e304f8e3
00e3f800
4.00E+05
13e30404
7c040000  <- Here is end of multiframe 4, and also end of ILA sequence
e3e30013  <- Here starts user data.
04f800e3
08e308e3
f8000808
ebebebf8
4.00E+302
e300f804
e3f8e304
4040404

Anders,

I will look into this. The data sheet is currently being revised to included a power up sequence (see attached). Are you following this sequence?

Regards,

Jim

 7450.SBAS756B_Draft3_01192017.pdf

Yes. By pure luck we do...

All,

I noticed a couple of registers were wrong with your file. Am I correct to assume you do not have SYSREF going to the ADC? I notice you are writing to the manual SYSREF registers. I duplicated your test with our hardware using the register settings below, with a clock at 400MHz and no SYSREF to the ADC and had no problems. There were a couple of minor changes made and some register writes removed. Please change the K value to 32 in your FPGA code before trying this. I am not sure why you had it set to 23. I think this may have been a typo. Also I looked at your captured ILAS data and it was correct. I can explain this in another post if needed.

Regards,

Jim 

ADC init
DBG (tx outvector) | 00 00 81
DBG (tx outvector) | 00 11 80
DBG (tx outvector) | 00 53 02
DBG (tx outvector) | 00 54 80
DBG (tx outvector) | 00 53 01
DBG (tx outvector) | 00 53 00
DBG (tx outvector) | 00 53 01
DBG (tx outvector) | 00 53 00
DBG (tx outvector) | 00 20 00
DBG (tx outvector) | 00 21 00
DBG (tx outvector) | 00 26 00
DBG (tx outvector) | 00 59 20
DBG (tx outvector) | 00 39 C0
DBG (tx outvector) | 00 3A 40
DBG (tx outvector) | 00 56 04
DBG (tx outvector) | 00 53 42
DBG (tx outvector) | 00 55 00
DBG (tx outvector) | 40 03 00
DBG (tx outvector) | 40 05 00
DBG (tx outvector) | 40 04 68
DBG (tx outvector) | 60 F7 01
DBG (tx outvector) | 60 00 01
DBG (tx outvector) | 60 00 00
DBG (tx outvector) | 40 03 00
DBG (tx outvector) | 40 05 00
DBG (tx outvector) | 40 04 69
DBG (tx outvector) | 60 00 80
DBG (tx outvector) | 60 01 04
DBG (tx outvector) | 60 06 1F
DBG (tx outvector) | 40 03 00
DBG (tx outvector) | 40 05 00
DBG (tx outvector) | 40 04 6A
DBG (tx outvector) | 60 16 02
DBG (tx outvector) | 60 17 40
DBG (tx outvector) | 60 17 00

Hello again.

Our vacation period is now over and we are both back at the office again...

We have tried your sequence above but no different results for us, I'm afraid.
What do you mean by " the ILA sequence is correct"? Is the content of our sampled ILA sequence what we should expect, or is it 'correct' related to a misconfiguration from our part?

When you try the sequence on your evaluation board; is it in on exactly the same chip type as we use or just a chip in the same family?
Can you sample the ILA sequence when you configure the chip and provide it to us as well?

As we now are turning every possible stone for solutions... how does your SPI sequence look like? Freqency, single/burst access e.t.c?

Bjorn,

What I mean is that per the setup you are using (LMFS, K, ect...) the parameters shown in your ILA capture were correct. Are you providing SYSREF from an external source? I never got an answer for this. The SPI will not work until the device see's at least 2 pulses of SYSREF. I used an ADS54J42 for my test. I have no way of capturing the ILA data right now. Our SPI uses burst mode. Can you do read backs with your SPI to verify you are writing properly? Do you issue a manual reset after power and clocks are provided to the ADC?

Regards,

Jim

Hi Jim,

Thanks for quick response.

We are still confused on the captured ILA sequences. We believe that we have configured the ADC to LMF=421 (see previous mails on setup)

Lane 0: (byte 13 downto 0)
0xbc_00_00_80_c0_cf_12_01_1f_00_1c_01_00_00

Lane 1:
0xa2_00_00_80_c0_cf_12_01_1f_00_1c_00_00_00

Lane 2:
0xba_00_00_80_c0_cf_12_01_1f_00_1c_1c_00_00

Lane 3:
0xa4_00_00_80_c0_cf_12_01_1f_00_1c_02_00_00

As can be seen, these are showing the same configuration, only lane IDs and checksums are different. But the field information is partly corrupt:

Fields according to JESD spec:

LID (lane ID), byte 2: Lane 0 has LID=0x01 (expected 0x00), lane 1 0x00 (expected 0x01. Are they swapped?). Lane 2 0x1c (expected 0x02), lane 3 0x02 (expected 0x03)

L (lanes in link), byte 3: L=0x1c (corresponding to 29 lanes(!). Expecting 0x03, as we have 4 lanes in the link)

F (bytes per frame), byte 4: F=0x00, as expected.

K (number of frames per multiframe), byte 5: K=0x1f, as expected (K=32)

M (number of ADCs in link), byte 6: M=0x01, as expected (2 ADC channels)

N (converter resolution), byte 7: N=0x12 (Resolution 19 bits. Expected 0x0d or 0x0f, depending on how the padded 14-bit sample is counted for)

N' (Sample size), byte 8 (4:0): N'=0x0f, as expected (16 bit samples)

SUBCLASSV (JESD type compliance), byte 8 (7:5): SUBCLASSV=0x6 (illegal value, expected 0x1)

S (Samples per ADC per frame), byte 9 (4:0): S=0x00, as expected.

JESDV (JESD version), byte 9 (7:5): JESDV=0x6 (illegal value, expected 0x1)

HD (High Density mode), byte 10 (bit 7): HD=0x1, as expected.

FCHK (checksum), byte 13: Doesn't match ILA content on any lane.

 

So our questions are:

1) Can we rely on the configuration? Illegal values in fields, strange number of lanes, etc, make us confused.

2) Can we be sure that our lanes are in the right order? Is our expected lane 0 really the true lane 0 in the link?

 

Best regards,

Anders F

Regarding your question about SYSREF and reset.

We set sync_b low EDIT: high
We toggle the physical reset pin
We set the register to enable manual SYSREF
We toggle SYSREF twice using soft commands
Then we start setup of the ADC as described before

I.e; yes we reset the chip after power and clocks are in place, yes we toggle SYSREF twice.

We have also tried to use a physical SYSREF with no difference.

Bjorn,

Can you read back the ADC registers? Why are you setting SYNC high? This needs to go low to start the CGS. After you set this low, can you verify the ADC is sending K28.5 characters? If this is not occurring, the device is probably not getting a valid SYNC low, or the device clock is not present, or power may be bad on one of the rails, or the part has become defective. 

Regards,

Jim

We start by setting syncb high initially as it in table 68, step 6, in draft 3 of the document says that we after setting up the device should pull the syncb low and then set it high, all to start a K28.5 synchronization sequence followed by the ILA sequence in an ordered fashion. To bi able to pull it low, it must first be high...

EDIT: I have now tried to set it low initially with no change in result.

I repeat the sequence we now try to apply:
wpoke 0x41230000 1 # Set o_syncb_n high
# Toggla PD_RESET: Register får defaultvärden, Låg -> Hög -> Låg
wpoke 0x41220000 3 # ADC physical reset low
wpoke 0x41220000 7 # ADC physical reset high
wpoke 0x41220000 3 # ADC physical reset low
wpoke 0x43c001d0 0x43 # fpga code soft reset
sleep 1
# Start writing to ADC registers:
write 0x000081
write 0x001180
write 0x005302
write 0x005480
# toggle SYSREF
write 0x005301
write 0x005300
write 0x005301
write 0x005300
write 0x002000
write 0x002100
write 0x002600
write 0x005920
write 0x0039C0
write 0x003A40
write 0x005604
write 0x005342
write 0x005500
write 0x400300
write 0x400500
write 0x400468
write 0x60F701
write 0x600001
write 0x600000
write 0x400300
write 0x400500
write 0x400469
write 0x600080
write 0x600104
write 0x60061F
write 0x400300
write 0x400500
write 0x40046A
write 0x601602
write 0x601740
write 0x601700

# Start setting up FPGA code
wpoke 0x43c001d0 0x50; sleep 1
wpoke 0x43c00110 0x010037F0
wpoke 0x43c00110 0x010037F3
wpoke 0x43c00110 0x010037F1; delay

# toggle syncb
wpoke 0x41230000 0; sleep 1 # set syncb low
wpoke 0x41230000 1 # set syncb high again

When reading back the registers we get the following:
root@wistom2017-petalinux:~# jesd.sh /dev/spidev32764.0 read
write 0x001180
read 0x805400 => 0x000080
read 0x802000 => 0x000000
read 0x802100 => 0x000000
read 0x802600 => 0x000000
read 0x805900 => 0x000020
read 0x803900 => 0x0000C0
read 0x803A00 => 0x000000
read 0x805600 => 0x000004
read 0x805300 => 0x000042
read 0x805500 => 0x000000
write 0x400300
write 0x400501
write 0x400469
read 0xE00000 => 0x000080
read 0xF00000 => 0x000080
read 0xE00100 => 0x000004
read 0xE00300 => 0x000000
read 0xE00500 => 0x000000
read 0xE00600 => 0x00001F
read 0xE00700 => 0x000009
write 0x400300
write 0x400501
write 0x40046A
read 0xE01600 => 0x000002
read 0xF01600 => 0x000002

Anything else you need us to try on our side?

Bjorn,

What FPGA are you using? What is your SYSREF rate? Did you provide the device clock and SYSREF before doing the reset and programming the ADC? Can you try using the following register writes from the attached document?

Regards,

Jim

6215.Low Level ADS54J42_LMF_4211.cfg

A: We are using a PicoZed SoC module with a Zynq 7030 device from Xilinx.

A: The SYSREF and clock is turned on before reset is applied with a grace second before I start to set up registers.

A: SYSREF = 1.5625MHz extracted from the same clock as CLKIN

CLKIN = 400MHz

When using your above sequence as follows (400MHz clock is allready applied):
I connot see any major difference in the ILA result.
As we don't trust the ILA content to be correct we have not tried to use the ADC with real analog data readout as we need to trust the ADC to be able to check the receiving FPGA modules...

Q: Is there a logical explanation why the ADC think it has 29 lanes?

Q: If so, why are the lanes numbered 0x01, 0x00, 0x1c, 0x02?

root@wistom2017-petalinux:~# jesd.sh  /dev/spidev32764.0 ti
poke 0x41230000 0    # Set syncb low
poke 0x43c001d0 0x40 # Start generating SYSREF at 1.5625MHz
EDIT: sleep 1
poke 0x41220000 3
poke 0x41220000 7    # set reset pin high on ADC
sleep 1
poke 0x41220000 3    # set reset pin low on ADC
sleep 1
poke 0x43c001d0 0x43 # Prepair our internal FPGA code
sleep 1
# Your proposed sequence:
write 0x000081
write 0x001180
write 0x005920
write 0x400468
write 0x400300
write 0x60F701
write 0x600001
write 0x600000
write 0x40046A
write 0x400300
write 0x601602
write 0x601740
write 0x601700
write 0x400469
write 0x400300
write 0x600104
write 0x600080
write 0x60061F
# Activate the FPGA code
poke 0x43c001d0 0x50
poke 0x43c00110 0x010037F0
poke 0x43c00110 0x010037F3
poke 0x43c00110 0x010037F1
poke 0x41230000 1 # set syncb high

root@wistom2017-petalinux:~# jesd.sh  /dev/spidev32764.0 read
write 0x001180
read 0x805400 => 0x000000
read 0x802000 => 0x000000
read 0x802100 => 0x000000
read 0x802600 => 0x000000
read 0x805900 => 0x000020
read 0x803900 => 0x0000C0
read 0x803A00 => 0x000000
read 0x805600 => 0x000000
read 0x805300 => 0x000000
read 0x805500 => 0x000000
write 0x400300
write 0x400501
write 0x400469
read 0xE00000 => 0x000080
read 0xF00000 => 0x000080
read 0xE00100 => 0x000004
read 0xE00300 => 0x000000
read 0xE00500 => 0x000000
read 0xE00600 => 0x00001F
read 0xE00700 => 0x000009
write 0x400300
write 0x400501
write 0x40046A
read 0xE01600 => 0x000002
read 0xF01600 => 0x000002
# Read status registerf from FPGA:
# Lane 0 ILA sequence:
poke 0x43c001fc 0 | peek 0x43c001fc => 0x1c010000
poke 0x43c001fc 1 | peek 0x43c001fc => 0x12011f00
poke 0x43c001fc 2 | peek 0x43c001fc => 0x0080c0cf
poke 0x43c001fc 3 | peek 0x43c001fc => 0x0000bc00
# Lane 1 ILA sequence:
poke 0x43c001fc 4 | peek 0x43c001fc => 0x1c000000
poke 0x43c001fc 5 | peek 0x43c001fc => 0x12011f00
poke 0x43c001fc 6 | peek 0x43c001fc => 0x0080c0cf
poke 0x43c001fc 7 | peek 0x43c001fc => 0x0000a200
# Lane 2 ILA sequence:
poke 0x43c001fc 8 | peek 0x43c001fc => 0x1c1c0000
poke 0x43c001fc 9 | peek 0x43c001fc => 0x12011f00
poke 0x43c001fc 10 | peek 0x43c001fc => 0x0080c0cf
poke 0x43c001fc 11 | peek 0x43c001fc => 0x0000ba00
# Lane 3 ILA sequence:
poke 0x43c001fc 12 | peek 0x43c001fc => 0x1c020000
poke 0x43c001fc 13 | peek 0x43c001fc => 0x12011f00
poke 0x43c001fc 14 | peek 0x43c001fc => 0x0080c0cf
poke 0x43c001fc 15 | peek 0x43c001fc => 0x0000a400

Bjorn,

The data you captured for ILA is not showing the 9C (Q) value. Please see attached. Is there a chance you are capturing data from another frame? This should be from the second multiframe and should start with 1C followed by 9C. The data shown is from our ADS54J60 that is from the same family as the ADS54J42.

Regards,

Jim

What you see in "Lane X ILA sequence" is the captured 14 bytes of ILA configuration data, i.e. what is present after the Q character.
There is no use for us to store the sync characters in FPGA memory. We only store the interresting part, i.e. the 14 ILAS bytes.

I'll try to detail which bytes are which using Lane 0 as an example:

# Lane 0 ILA sequence:

                                       READ DATA        ILA byte number corresponding to read data  
poke 0x43c001fc 0 | peek 0x43c001fc => 0x1c010000       03 02 01 00
poke 0x43c001fc 1 | peek 0x43c001fc => 0x12011f00       07 06 05 04
poke 0x43c001fc 2 | peek 0x43c001fc => 0x0080c0cf       11 10 09 08    
poke 0x43c001fc 3 | peek 0x43c001fc => 0x0000bc00       xx xx 13 12

1C is not a ILA byte parameter. The fourth octet (03 byte) is the # of lanes -1, which we record as a 3. I have captured the ILA data with an ADS54J42EVM using your settings and I get the following:

Lane 0 : 0, 0, 1, 3, 0, 1F, 1, D, 2F, 20, 80, 0, 0, 43

All of the other lanes have a different ID and checksum. As far as I can tell, the data is coming out correctly except for the checksum. This value should be the sum of the first 12 parameters then mod 256. I cannot figure why we are seeing a 43 for lane 0. I am checking with the design team regarding this.

Regards,

Jim

Bjorn,

 

For the checksum issue:

 

Then check sum is summation of all 20 fields then mod256.

The 20 fields span over 13 Octets. If you sum each field individually in this example, you would get the correct check sum for each lane. I was originally combining a couple of the fields, thus giving me a wrong a checksum value.

 

Regards,

 

Jim

 

Really strange.

I have captured the ILAS sequence using chipscope once again:

I have also created a script that extracts the ILAS fields (with +1 compensation for the fields thar are value - 1 entered):

DID: 0 BID: 0 ADJCNT: 0 LID: 1  PHADJ: 0 ADJDIR: 0 L: 29 SCR: 0 F: 1 K: 32 M: 2 N: 19 CS: 0 NP: 16 SUBCLASS: 6 S: 1 JESDV: 6 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: 188
DID: 0 BID: 0 ADJCNT: 0 LID: 0  PHADJ: 0 ADJDIR: 0 L: 29 SCR: 0 F: 1 K: 32 M: 2 N: 19 CS: 0 NP: 16 SUBCLASS: 6 S: 1 JESDV: 6 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: 162
DID: 0 BID: 0 ADJCNT: 0 LID: 28 PHADJ: 0 ADJDIR: 0 L: 29 SCR: 0 F: 1 K: 32 M: 2 N: 19 CS: 0 NP: 16 SUBCLASS: 6 S: 1 JESDV: 6 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: 186
DID: 0 BID: 0 ADJCNT: 0 LID: 2  PHADJ: 0 ADJDIR: 0 L: 29 SCR: 0 F: 1 K: 32 M: 2 N: 19 CS: 0 NP: 16 SUBCLASS: 6 S: 1 JESDV: 6 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: 164

Here I think it is strange that the NP value is smaller than N (or I just missunderstand the meaning), SUBCLASS=6, JESDV=6, L=29 and LID=28.

Can you please forward our strange ILAS as well to the design team and ask if they have a clue what is going on?

I hope we have not heard from you due to you waiting on feedback?

Any way. I would like to highlight the differences between our expected ILAS data:

DID: 0 BID: 0 ADJCNT: 0 LID: 0  PHADJ: 0 ADJDIR: 0 L: (4-1=3)   SCR: 0 F: (1-1=0) K: (32-1=31) M: (2-1=1) N: (16-1=15) CS: 0 NP: (16-1=15) SUBCLASS: 1 S: (1-1=0) JESDV: 1 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: xxx
DID: 0 BID: 0 ADJCNT: 0 LID: 1  PHADJ: 0 ADJDIR: 0 L: (4-1=3)   SCR: 0 F: (1-1=0) K: (32-1=31) M: (2-1=1) N: (16-1=15) CS: 0 NP: (16-1=15) SUBCLASS: 1 S: (1-1=0) JESDV: 1 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: xxx
DID: 0 BID: 0 ADJCNT: 0 LID: 2  PHADJ: 0 ADJDIR: 0 L: (4-1=3)   SCR: 0 F: (1-1=0) K: (32-1=31) M: (2-1=1) N: (16-1=15) CS: 0 NP: (16-1=15) SUBCLASS: 1 S: (1-1=0) JESDV: 1 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: xxx
DID: 0 BID: 0 ADJCNT: 0 LID: 3  PHADJ: 0 ADJDIR: 0 L: (4-1=3)   SCR: 0 F: (1-1=0) K: (32-1=31) M: (2-1=1) N: (16-1=15) CS: 0 NP: (16-1=15) SUBCLASS: 1 S: (1-1=0) JESDV: 1 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: xxx

compaired to what we actually get with incorrect values marked in red:

DID: 0 BID: 0 ADJCNT: 0 LID: 1  PHADJ: 0 ADJDIR: 0 L: (29-1=28) SCR: 0 F: (1-1=0) K: (32-1=31) M: (2-1=1) N: (19-1=18) CS: 0 NP: (16-1=15) SUBCLASS: 6 S: (1-1=0) JESDV: 6 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: 188
DID: 0 BID: 0 ADJCNT: 0 LID: 0  PHADJ: 0 ADJDIR: 0 L: (29-1=28) SCR: 0 F: (1-1=0) K: (32-1=31) M: (2-1=1) N: (19-1=18) CS: 0 NP: (16-1=15) SUBCLASS: 6 S: (1-1=0) JESDV: 6 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: 162
DID: 0 BID: 0 ADJCNT: 0 LID: 28 PHADJ: 0 ADJDIR: 0 L: (29-1=28) SCR: 0 F: (1-1=0) K: (32-1=31) M: (2-1=1) N: (19-1=18) CS: 0 NP: (16-1=15) SUBCLASS: 6 S: (1-1=0) JESDV: 6 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: 186
DID: 0 BID: 0 ADJCNT: 0 LID: 2  PHADJ: 0 ADJDIR: 0 L: (29-1=28) SCR: 0 F: (1-1=0) K: (32-1=31) M: (2-1=1) N: (19-1=18) CS: 0 NP: (16-1=15) SUBCLASS: 6 S: (1-1=0) JESDV: 6 CF: 0 HD: 1 RESERVED: 0 RESERVED: 0 FCHK: 164

The initialization sequence used is the one given by you.

Please indicate that you are waiting for feedback, or are trying to understand what is wrong at our side some other way.

We would like not to have to redesign the board with another ADC with all the extra cost and lost time to market due to not getting this ADC up and running but we are getting closer to such a decision.
Do you have any other ADC options from TI to recommend that would replace this one?

EDIT: We have sent one board for ADC replacement to rule out a faulty chip due to problems we might have had during the board bringup process. Just to be sure.

 

Bjorn,

I am waiting to here from the design team to see if there is any way this data could have been corrupted. In the mean time, I am having our firmware development team create a build that will allow me to monitor the ILA data on a Xilinx KCU105 development board. Which Xilinx board are you using? Is there a chance you can send me your project file so I can duplicate your test on our hardware? We also have a KC705, VC707, and ZC706 we could try this on.

Regards,

Jim 

Ok. Sounds great.

We are running on a proprietary motherboard with an Avnet SOM module PicoZed 7030 (AES-Z7PZ-7Z030-SOM-I-G) with a Xilinx zynq (XC7Z030-1SBG485) mounted , i.e. a standard module on a proprietary motherboard.
On the motherboard the clocks are synthesized by an AD9518-4 from Analog Devices.

We will receive an evalkit in the end of this week consisting of an ADS54J42EVM and an TSW14J56EVM to try to repeat what you do and to be able to compare the control signals to the chip.
Maybe you have a design we should use to test on this eval setup?

No use for you to get our files as they will not suit any board you can aquire I'm afraid.

We eagerly wait for you results and feedback.

Bjorn,

We have a special version of software that runs on the TSW14J56EVM that allows you to capture the ILA data. This is what I did and sent to you in a past post. Based on what I sent you, this is why I do not think this part has an issue.

Regards,

Jim

Can you please send me the setup files for the eval kit, attached here, in a PM or to my corporate email address that I think you have since before?
I cannot find in in the previous forum posts.

I hope, and think, that it is not the device itself but something we do incorrectly. In registers, in the sequence of start up behaviour e.g. when and how clocks are applied or other signals. Maybe we have hit some new unknown relationship... That is what I hope to be able to find by comparing the physical startup behaviour of the pins on our design and the eval board using the same settings...

Regards
Björn

We received the TSW14J56 board today and the ADS54J42EVM board yesterday.
Unfortunately there are no sign at all of a USB connection when connecting the USB3 cable to the PC.
I have installed the two eval programs necessary, as administrator, according to the numbered follow-me instruction in the documentation.
I have tried to connect the cable to three different computer using two different USB3 cables but none of the computers even recognizes that a USB device has been connected at all.
I think the USB port on the eval board are non-functional :o(

So, my hope to quickly be able to compare startup behaviour and test our sequences on another board are not going to happen...

Should I open up a new web-case regarding this problem or do you have any tricks up the sleeve I can try... I'm pretty familiar with the Cypress FX3-circuit as I have been involved in a project recently using this circuit.

Bjorn,

What version of Windows are you running on your PC? You must install the HSDC Pro GUI as a system administrator and run the exe as a system administrator. Give this a try.

Regards,

Jim

I run Windows 10 on my computer.
I have tried to connect the board to a Windows 7 and a Linux board and expect at least to see an unsupported USB device poping up on either of them.
I se nothing in Linux using dmesg, and not a trace of anything in device manager on either Windows 10 nor Windows 7...

I could test to connect the board to the FX3 development environment next week to see if I can connect to the Cypress in programming mode at all. It behaves as it is unprogrammed and not booting.

I have checked all jumpers and they seem to be in default position as well as measuring 5V coming from the USB connector.

I'm out of office until monday from now but will be able to work remotely with our initially problematic proprietary board if you have any progress on your side.

Bjorn,

What is the current available from the supply connected to  the TSW14J56EVM? Do all power status LED's (blue) turn on after power is applied? Below is from the User's Guide. Does this appear in your device manager?

Regards,

Jim

For the TSW14J5x, the .exe file installs the Cypress USB 3.0 drivers during software installation. The USB

3.0 driver, called "Cypress FX3 USB StreamerExample Device", should be located in the Hardware

Device Manager under the Universal Serial Bus controllers as shown in Figure 6.

I