Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

M24256-DFCS6TP/K serial EEPROM unreliable

Status
Not open for further replies.

davide.b

Newbie level 4
Joined
Nov 28, 2017
Messages
5
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
56
Hello everyone,

I have been working at a design for a product that features the M24256-DFCS6TP/K I2C EEPROM by ST in the WLCSP packaging. A batch of PCBA were ordered from a company. When I started programming the boards, I noticed that the EEPROM did not work correctly on some boards. That is to say, while on some boards the code I wrote works well and I am able to read from and write to the EEPROM, on some other boards the write operation fails while the read operation is fine and on some other boards I can neither read or write.
After some investigation, I was able to exclude PCB manufacturing issues and bad soldering issues.
Has anyone had the same problem with this kind of package? Do you know what could be the cause of such an unreliable performance across multiple boards? Maybe some particular heat curve in the reflow process is necessary? Maybe some special layout requirements?
The space on the PCB is quite tight, but maybe I could fit the UTDFN package instead. Would you think that is going to be more reliable?
 

Hi,
Do you know what could be the cause of such an unreliable performance across multiple boards? Maybe some particular heat curve in the reflow process is necessary? Maybe some special layout requirements?

The first place to find those answers is the manufacturer:
They have an internet page for this product: https://www.st.com/content/st_com/e...ial-eeprom/standard-i2c-eeprom/m24256-df.html
Then scroll down to "Technical Notes & Articles " and find this document: "TN0991: Description of WLCSP for STMicroelectronics EEPROMs and recommendations for use "

Soldering problems depend on so many parameters: Temperature profile, age of devices, solder contents, age of PCB and so on....This makes it difficult to give good assistance.

****
"did not work correctly" is no error description.
--> If you need help with this, then you need to provide a detailed error description in a way that a user here can verify your device behaviour with the datasheet or another real circuit.

****

I doubt that there are general problems with this device...

****
Maybe there are only sodering problems.. but for me it sounds as there are additional issues.
* maybe the power supply is not within specification.
* maybe the communication is not within specification.
* maybe uncontrolled pin states during power up...
We can´t verify this, because you didn´t give enough information...

Klaus
 

It may be that your design is only working by accident, ie it is operating near the conditions specified by the manufacturer, such as switching speed, selected pullup values, or some factor of the board's routing layout. In general, we can not blame the device without considering all the interactions, for example, is there any other I2C component tied on the same bus?
 

provide a detailed error description
What's happening is that the microcontroller is correctly putting on the bus the address of the device. The EEPROM is then supposed to pull down the data line on the 9th clock pulse to issue an ACK signal. The problem is that this is not happening. Scoping clock and data shows the correct address, correct voltage levels and pulse widths, with the only problem being the missing ACK.
I do have other devices on the same I2C line, but they don't seem to be affecting in this instance. As I mentioned, it appears that only the master is affecting the bus.
maybe the power supply is not within specification.
I checked the supply voltage and it is 3V as by design, which is within specifications.
maybe the communication is not within specification.
As previously mentioned, scoping the signals reveal correct timings and voltage levels. I also changed the pull-ups with more aggressive ones (are now 2.2k) with no result. The signal does rise faster now, but the EEPROM still does not respond.
maybe uncontrolled pin states during power up
What exactly do you mean by this? The EEPROM pins are quite straightforward, as there are only 3 hardware address select, Vcc, GND, SDA and SCL, plus a write protect that needs to be left floating or low, although neither configuration worked. Can the microcontroller side generate problems to the pin states?
 

Did you check if the control pins are allways stable without presence of any spurious ? I'm assuming you have provided proper decoupling capacitor near to Vcc pin to ground.
 

Did you check if the control pins are allways stable without presence of any spurious ? I'm assuming you have provided proper decoupling capacitor near to Vcc pin to ground.

Now that you mention it, I did forget to place proper decoupling. I am aware of the importance of them, but it went over my head. Nonetheless, after scoping the board, none of the EEPROM pins seems to have any spurious signal superimposed on the regular control signal. I2C switch with right timing, Vcc and GND are solid, as well as address pins and write protect pins.
 

For anyone that was wondering, replacing the chips solved the problem. So the issue was actually faulty chips. Need to investigate some more on how those chips became faulty...
 

Hi,

please confirm that this was NO soldering problem like mentioned in post#1.
The chips really were faulty?

Klaus
 

It is highly likely that it was not a soldering problem, as during the first phases of the investigation, the chips that would later be deemed faulty were removed from the PCB and deadbug soldered onto an external board that was in turn connected to the original PCB via wires attached to different solder points than the device footprint. I think this is enough to exclude soldering problems.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top