- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
06-25-2015 11:25 AM
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?
Solved! Go to Solution.
07-28-2015 10:39 AM
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.
07-28-2015 11:05 AM
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
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.
07-28-2015 02:13 PM
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.