RE: nRF52 eng C vs rev 1 unfixed issues

ovrebekk — Wed, 04 Jan 2017 16:46:04 GMT

Hi Fabien
I am always happy to help!
Have a nice day, and happy new year :)

RE: nRF52 eng C vs rev 1 unfixed issues

Fabien Comte — Wed, 04 Jan 2017 10:01:07 GMT

Hi Torbjørn,

Thank you for your response and your transparency.

Best regards Fabien

RE: nRF52 eng C vs rev 1 unfixed issues

ovrebekk — Wed, 04 Jan 2017 08:18:22 GMT

Hi Fabien

It is very costly to do a chip respin, both in terms of engineering time and money, and since we are in a very competitive market we always have to make a trade off between improving existing products and developing new ones.
To put it another way: We could spend more engineering hours and money to make our chips bug free, but then they would become so expensive that very few would buy them ;)

If we find critical issues for which no workaround exists then we will obviously fix it, but if there is a software or hardware workaround available then it might never be fixed. When a hardware issue requires a software workaround we will usually update the SDK drivers to automatically apply the workaround, so that customers don't have to implement the workaround on their own.

The RX sensitivity reduction is for the CSP package only, the QFN does not have this problem. Since we don't want to release a separate specification for the CSP and QFN packages we just put the sensitivity reduction in the errata. If both the QFN and CSP had this problem we would probably update the specification instead.

There are no current plans to release a new version of the nRF52832, but this could change in the future.

To summarize I agree it's not ideal that we can't fix all the bugs in our products, but as explained it is not practically feasible to do so. If you feel that your design is held back by a hardware bug you should contact us, and we will do our best to help :)

Best regards
Torbjørn