nRF52840 Lead Finish of the BGA Balls

[John]

We are having a very difficult time soldering the nRF52840 to the PCB. Our Operations Department is asking what the lead finish of the BGA balls is. Would be great to get on the phone with you guys to discuss all the things we have tried. You might have some ideas. Thank you!

[John]

Hi Kaja,

We are still trying to resolve why our nRF52840 design is having some resets when we run the baord at -20C. For a long time we thought we were having a soldering issue with the BGA, but now we are not sure. If we run 50 boards in our environmental chamber at -20C, after two days about 1/2 of the PCBs will have experienced a reset. The reset reason reported by the nRF52840 is a power on reset. We have been monitoring the 3.3V supply and the 1.3V supply and we don't see them ever going away.

Typically, our design utilizes low power mode so we can get the longest battery life. We tried a test where we switched to constant latency mode, and now we never see a reset on any PCB! We can't ship out product with constant latency turned on because that increases our power consumption too much, but perhaps this is a clue to what is going on. As I mentioned above, we only see this problem when we soak the PCBs at -20C or lower. Does the 32MHz crystal stay on at all times in constant latency mode? If the 32MHz crystal is taking a little longer to start up at -20C, could that cause a reset? Typically, our device is in low power mode 99.9% of the time. We do wake up every second to do some housekeeping tasks. 

Thank you,

John Araujo

[John]

Hello,

Haven't heard from you folks in a couple of days. Would really appreciate some help. I have some new information. Turns out we only use the HFXO when we use the BLE radio. We ran a test where we turned off BLE so we are never using the HFXO. The product goes to sleep and wakes up using the HFINT only. Will still see resets on our boards when they are running at -20C. If we switch to constant latency mode, we never see any resets. So I don't think the issue is with the 32MHz crystal. I think we are running into an issue when we are waking up from sleep. Perhaps we can run a test where we sleep/wake-up a lot more often to see if this increases our error rate. This is a huge problem for us. We have delayed the release of this product for two months while we've been trying to fix this. We thought it was a soldering issue and we have recently upgraded from a 7-zone to a 10-zone reflow oven. I'm thinking now the problem isn't a soldering issue. Hope to hear from you soon.

[Kaja]

Hi John, 

sorry for the delayed response, I was on business travel last week. 

But a question are you using LDO or DC/DC?

Best regards,
Kaja

[John]

Hello Kaja,

Thank you for getting back to us. We are using the DC-DC 1 per Figure 212 in your product spec. We don't use USB or NFC. We have made some code changes that seem to be helping this problem significantly. 

[John]

I'd like to bring our FW engineer into this discussion but I don't see how I can add him. I'll try converting this to a public question. By the way, we have tried the internal LDO and DC-DC 1 and we get the same failure rate.