We are using NXP’s MMA8653FC accelerometer sensor in a vibration sensing product (vehicular). We developed and tested, both in the lab and in the field, over 40 prototypes without issue in the past 18 months. Following pilot production we have experienced a failure rate of around 9%, some 450 assemblies during the self-test procedure. After investigation we discovered that the device in the failed assemblies are sending the same value for Z-axis, 0x80 or 0x79 (we are using 8 bit in our application).
Further research within the forum identifies the problem of ‘stiction’ (see attachment) however, this was apparently addressed and rectified in this part number 2013. Our production stock is from week 42, 2017. The devices were stored for 14 months prior to mounting in late April, 2019. The re-flow process shows no abnormalities. We are in the process of lodging the necessary paperwork for NXP to investigate but, as this will take some time, I’d like to ask if anyone else has any experience or feedback regarding the same?
Thanks in advance.
I too have been having this issue, out of 10 sample boards of a new design I had 2 failures of the exact same mode you describe (z axis always returning 0x80) which is not an acceptable rate. I reported 20.05.19 so after you posted this question.
I have been in contact with NXP and provided date codes etc but I'm yet to get a response. It actually looks like I'm going to have to design the part out as we cannot be sure we will catch this at our EOL test as we don't know the cause. Lucky I've caught it before we went into production.
Thanks for taking the time to respond, it is appreciated. Your experience with the part has effectively confirmed our problem, in percentage terms as well.
Unfortunately for us, the problem only manifested once we did pilot production – we had no issue with the R&D parts for whatever reason. As a result we have had to dispose of around 10% production.
The R&D parts we used were a much earlier date code than production parts. Can I ask what the date code is for the parts you’ve had the issue with?
For the record, we had no success in obtaining any support from our local NXP office (Singapore), even after completing all the necessary paperwork and sending samples. They can’t assess samples which have been mounted.
The coding on the parts I have are:
the packet has a date of 2018/09/07 on a label, sorry I cannot be more specific as the sample boards were manufactured by one of our suppliers. Our supplier has raised a case with Verical and if samples are required I'll have to hope they still have some spare as the rest are all mounted.
Out of interest I tried the recovery method described by Jose Alberto Reyes Morales and it has worked on one of the faulty devices. I intend to check it again later in the week to see if the problem comes back.
Hopefully something will come of the case opened by Verical, as the NXP contact in Germany couldn't tell me anything without official quality issue documents.
It is great that you were able to identify the problem before production. Although we have disposed of 10% post PCBA production we were at least fortunate enough to identify the issue prior to overmoulding. This would have increased the cost of loss considerably.
Our disty, Future Electronics, were unable to progress any further with NXP as all our components were mounted and they would not accept samples for analysis, despite shipping them to Singapore at our disty's expense. To be frank they have completely ignored the problem and have been of no assistance whatsoever. I very much doubt they will publish this response but kudos to the community moderator if they do.
You have made the right decision in designing the part out - we will do the same for next production. Without NXP's support we have no option.
I would be keen to know what you end up using. I will contact you via LinkedIn if my reply isn't published.
All the best,
First, please make sure the soldering process is done according to these recommendations.
Peak Package Body Temperature(PPT): 260 ℃
Maximum Time at Peak Temperature: 40 s
For detailed information about how to handle the accelerometer during manufacturing process and solder profile, please recommend the customer to check the App Note AN1902: https://www.nxp.com/docs/en/application-note/AN1902.pdf
As you properly mentioned, there was a known issue with stiction of Z-axis of the NXP accelerometers MMA845x and MMA865x families, but this issue was corrected in 2013, so, I recommend you to check the marking of the accelerometers and make sure they are recently manufactured devices.
For parts that used to have this stiction issue, there was a “recovery” method, or a way to make sure the problem is caused by a mechanical issue of the internal MEMs structure, this is done by slight tap on the part. Remember that the problem was that the MEMS structure inside the accelerometer gets stuck, so the workaround was to tap it/hit it with your finger on top of the accelerometer to un-stuck it.
There seems to be no new reports of this issue for the MMA865x family in our technical support system tool.
In case you find that these are recent manufactured devices and are soldered according to the NXP recommendations, then a CQC failure analysis with the NXP Quality engineers would be recommended. You would need to contact your distributor to start a CQC (failure analysis) process.
Have a great day,
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
Thanks for the prompt response. We have checked the thermal profile report for the production re-flow process and, being leaded solder, it is certainly under the peak package and time parameters of the devices quoted spec. We've also checked our records, including a visual inspection, of the remaining stock and confirm the manufacture date according to the label on the reel is week 42, 2017. The device itself is marked 653 AHP.
We had already undertaken the 'recovery' method you outlined, having discovered a sharp tap would free up the device and allow it to work, however we had a considerable recurrence of the issue in the same devices after we re-tested 2 days later (this very morning). Do you have any comment on this?
We have had contact from NXP Singapore, via our disty, and are commencing the required process in order to return some examples for analysis.
It does appears to be an issue with the MEMS internal structure, so, yes, the CQC failure analysis you started with your disty is the recommended path to follow.