Reply
Posts: 8
Registered: ‎04-30-2015
Accepted Solution

Si5340 Startup/Communication Problem

I've been having trouble trying to communicate with a blank Si5340-B-A-GM on my own PCB. I believe I've finally tracked down the issue to the crystal. For our application, we required a 49.152MHz xtal so we could switch the inputs between a system 49.152MHz signal and the crystal. When I probed the PCB, the crystal was not oscillating. The crystal I used is an AVX, p/n: CX3225GB49152P0HPQCC. 18pF, 50ohm ESR. I realise that this xtal is not one of the recommended ones, but was the only available option I could find.

 

I found a comment in the reference manual (Si5341-40-RM.pdf, rev 0.95), on pg 58, §14.1 where it states that base devices are "...configured by default to use a 48 MHz crystal on the XAXB reference and a 1.8V compatible I/O voltage setting for the host I2C/SPI interface."

 

I'm interfacing to the Si5340-EVB, so I'm using 3.3V over 4-wire SPI, but I believe the inputs are 3.3V tolerant.

 

So is the problem with the xtal not oscillating have to do with the xtal frequency or the xtal ESR?

 

Thank you,

 

Carson

Posts: 63
Registered: ‎09-10-2014

Re: Si5340 Startup/Communication Problem

Hi,

 

The issue is due to both the crystal ESR being too high AND the crystal capacitance load being too high.

If you can switch to a crystal that is closer to our recommendations for CL and C0, then the 50 ohms ESR would still be okay.

 

The crystal frequency is not an issue.

 

Regards,

Hari

Posts: 8
Registered: ‎04-30-2015

Re: Si5340 Startup/Communication Problem

I checked my schematic and layout half a dozen times. Even measure every pin voltage to confirm there wasn't a PCB or assembly issue.

 

So I'm not sure what happened with the ICs on my board, but I ended up buying an external programmer but still couldn't communicate. Then I purchased the 44-pin adapter, and pre-programmed the ICs and had our assembler switch them on 2 boards. Then, I could magically talk to them with either the eval board or the programmer! (A lot of extra expense just to get things working.)

 

Still puzzled, I cleaned up the pads on the 2 problem ICs and put them into the 44-pin programming adapter. I could talk to them (I saw the correct ID), but when I tried a simulated write (enabled debug option) I had nothing but read back errors (NVM validation failed). Same for both ICs.

 

NVM validation failed:

Addr 0x0018: expected 0xF0, contains 0xFE

Addr 0x0021: expected 0x08, contains 0x09

Addr 0x002C: expected 0x2F, contains 0x39

Addr 0x002D: expected 0x55, contains 0x01

Addr 0x002E: expected 0x8E, contains 0x8B

Addr 0x0030: expected 0x8E, contains 0x00

Addr 0x0032: expected 0x8E, contains 0x00

Addr 0x0034: expected 0x8E, contains 0x00

Addr 0x0036: expected 0x1B, contains 0x15

Addr 0x0038: expected 0x1B, contains 0x00

Addr 0x0039: expected 0x01, contains 0x00

Addr 0x003A: expected 0x1B, contains 0x00

Addr 0x003B: expected 0x01, contains 0x00

Addr 0x003C: expected 0x1B, contains 0x00

Addr 0x003D: expected 0x01, contains 0x00

Addr 0x0041: expected 0x05, contains 0x04

Addr 0x0042: expected 0x05, contains 0x00

Addr 0x0043: expected 0x05, contains 0x00

Addr 0x0044: expected 0x05, contains 0x00

Addr 0x0112: expected 0x06, contains 0x04

Addr 0x0113: expected 0xCC, contains 0x09

Addr 0x0114: expected 0x00, contains 0x3B

Addr 0x0117: expected 0x02, contains 0x01

Addr 0x0119: expected 0x33, contains 0x3B

Addr 0x011A: expected 0x01, contains 0x00

Addr 0x0126: expected 0x02, contains 0x01

Addr 0x0127: expected 0xCC, contains 0x09

Addr 0x0128: expected 0x00, contains 0x3B

Addr 0x012B: expected 0x06, contains 0x01

Addr 0x012D: expected 0x33, contains 0x3B

Addr 0x0140: expected 0x01, contains 0x00

Addr 0x0212: expected 0x01, contains 0x00

Addr 0x0218: expected 0x01, contains 0x00

Addr 0x021C: expected 0x01, contains 0x00

Addr 0x0222: expected 0x01, contains 0x00

Addr 0x0226: expected 0x01, contains 0x00

Addr 0x022C: expected 0x01, contains 0x00

Addr 0x0231: expected 0x01, contains 0x03

Addr 0x0232: expected 0x01, contains 0x03

Addr 0x0233: expected 0x01, contains 0x03

Addr 0x0234: expected 0x01, contains 0x03

Addr 0x0239: expected 0x8A, contains 0x0E

Addr 0x023A: expected 0x00, contains 0x01

Addr 0x0253: expected 0x01, contains 0x00

Addr 0x025C: expected 0x3F, contains 0x00

Addr 0x026B: expected 0x42, contains 0x35

Addr 0x026C: expected 0x50, contains 0x33

Addr 0x026D: expected 0x5F, contains 0x34

Addr 0x026E: expected 0x56, contains 0x30

Addr 0x026F: expected 0x30, contains 0x42

Addr 0x0270: expected 0x42, contains 0x50

Addr 0x0271: expected 0x30, contains 0x31

Addr 0x0272: expected 0x31, contains 0x00

Addr 0x0306: expected 0x45, contains 0x87

Addr 0x0310: expected 0xE0, contains 0x00

Addr 0x0311: expected 0x19, contains 0x00

Addr 0x0315: expected 0x24, contains 0x00

Addr 0x0316: expected 0xF4, contains 0x00

Addr 0x090E: expected 0x02, contains 0x00

Addr 0x091C: expected 0x03, contains 0x04

Addr 0x0943: expected 0x01, contains 0x00

Addr 0x0949: expected 0x0F, contains 0x09

Addr 0x094A: expected 0xF0, contains 0x90

Addr 0x0A03: expected 0x03, contains 0x01

Addr 0x0A05: expected 0x03, contains 0x01

Addr 0x0B4A: expected 0x0C, contains 0x0E

 

Bad chips??

I've been using our assemblers for some time, never any issues with all sorts of QFN and BGA parts. I believe our assemblers purchased the ICs from Digi-Key, and they would have baked them if needed, so I don't see how the assembly process would have caused any issues.

 

Only thing I can think of is the chips were bad or had static/other damage?

 

Additionally, the crystal I used with the non-compliant ESR and capacitance now work on the boards with the pre-programmed ICs, although the frequency is a bit out.

 

Carson

Highlighted
Posts: 63
Registered: ‎09-10-2014

Re: Si5340 Startup/Communication Problem

Hi,

 

Can you try writing to RAM (in stead of trying to do an NVM download) on the "bad" units ?

 

Also, if you please ship the units back to us (through digikey as a RMA) for checking. The NVM process needs a very stable supply on VDDA and VDD core. Any noise/voltage dips either causes  band NVM (on a good blank part) or NVM download error on power (on a good NVM-ed part).

 

Please check the supply transients while Si5341 is powering up. If you see voltage spikes of 200 mV or larger, it points to the above issue.

 

The crystal would need a change for the sake of reliability.

 

Also, please raise a tech. support ticket ( http://www.silabs.com/support/Pages/default.aspx ) because this might need RMA support from our end.

 

Regards,

Hari