Possible Damage from camera flash nRF52832-CIAA-R (WLCSP)

Hello,

I am working with a board (currently embedded inside a clear container I cannot easily take it out of) with an nRF52832-CIAA-R. We were taking photos of it with a strong flash (think umbrella lights and similar, so very high intensity) and it is now no longer functioning. 

A possibility we are exploring is that the camera flash could have tampered with the internal flash storage of the nRF52832 SoC, or some other part of the chip is not behaving as expected. Is this physically possible? We are not sure how this could happen otherwise. We have a few other components in WLCSP and are exploring faults in those as well. The nature of this fault seems to be indicative of either (1) a hardware failure or (2) a firmware failure as it is not advertising on BLE anymore and indicator lights are not turning on. We plan on trying to access our SWD pins later today if we can physically reach them.

For context on timeframe, the incident occurred at about 1500 hours PST yesterday, and we are still observing a lack of responsiveness from the device.

JC

Parents Reply Children
  • Hello,

    I read that documentation. Unfortunately, power cycling is not an option in this case, as this board is encased in a capsule we cannot open. We plan to attempt JLINK interfacing today as we have managed to expose those pins.

    Will update later. 

    Is there any other possibility of digital modules being affected? I have heard this happen on other WLCSP packages (for example the Raspberry Pi 2's power module would reset the chip when exposed to flash photography)

    JC

  • Just to clarify, we have not followed the guidelines for protecting the chip and plan on doing so next revision. I am attempting to diagnose this specific issue and see if we urgently need to fix this or if we can let it wait for a bit.

    JC

  • I guess it's possible to perform a failure analysis in our QA lab, but assume if the chip is fully enclosed that will be difficult. Hopefully you are able to make some findings over the SWD interface of the state of the chip. Considering you have not protected the chip I think the best in any case it to make a new revision and check if the problem goes away after adding protection.

    Not directly related, but: a good idea can also be that you have some kind of watchdog timer in your application, so in case it get stuck it can reset to recover. Not sure if that would help in this case though.

    Kenneth

  • How would you suggest testing it in a QA environment? We might try analyzing this failure ourselves with the other boards we have on hand.

    JC

  • Just an update: we managed to powercycle and it now works, now we are just trying to figure out the root cause of the issue; could the RAM (or other volatile storage media) have been affected photonically?

    Trying to find a good way to fix this issue as we would have no way of fixing this in production.

    JC

Related