We’ve been working with our Nordic Application Engineer over the weekend, although he was off yesterday as it was Martin Luther King day. He’s been somewhat able to recreate our problem in that he can cause some instability by using a hairdryer to rapidly change temperature — however, we generally do the opposite in our testing and rapidly cool the devices to exhibit the behaviour. We’ll continue to work with him today and hopefully he can create a low temperature test environment.
In the meantime, we have started to qualify an external crystal as a low-frequency clock source as that’s a potential hardware fix. Initial testing results show the expected stability (although our old firmware does as well; which is the enigma here). I also spent the weekend adding this component to all of our designs (which required also changing the programming connector on each board due to space considerations), and we’ll re-run samples of every device with it populated for testing. Whilst regression testing yesterday, Lorenzo noticed we were consuming too much current — so we’ll also figure that out today — but that’s why we regression test stuff, right? 🙂
Just to clarify the exact nature of the problem: it’s a fringe-case where rapidly cooling the silicon causes instability with the Bluetooth radio stack. We were initially optimistic this was just a bug in our code (as we control that), but as we’ve dug deeper, it’s become apparent it’s the Nordic SoftDevice causing an “assert”. Because we don’t necessarily know everyone’s use-case for our devices, we want to make sure we ship the best product we can and replacing product in the field is far more time-consuming and expensive than taking a little bit extra time to understand an issue. We’re still [somewhat] hopeful there’s a software fix, especially given our old stack of firmware + SoftDevice + SDK doesn’t seem to exhibit the problem.
We’ll make another update in the next 48-hours.