OTA Final Production Testing

[jumpingfool]

We are preparing a product (based on nRF52840) for manufacturing and currently defining the production test process.

The product is hermetically sealed with no external ports and so it is not possible to access the UART for DTM during final test. We are therefore exploring options to test the product OTA.

We have reviewed the whitepaper describing an OTA testing approach using the LiteOn Bluetooth Advanced tester at:

http://infocenter.nordicsemi.com/pdf/nwp_028.pdf

The BLE_SMART_TX_RX_PER test looks to be an excellent fit for our requirements.

However, we also need to write configuration information over BLE to the product (serial number, etc), with a Windows based PC acting as a central. So to optimise the test flow we would like to understand if we can reasonably use the PC in place of the LiteOn equipment for functional testing.

If so what operations between the PC and product would be recommended to ensure maximum verification confidence? We propose to check advertising RSSI then connect and time a data transfer burst, comparing performance a against a golden sample. Anything else we would consider? Any risks with this approach?

[Andreas]

Hi,

 

For these test you need the Litepoint IQxel instrument, this is what is doing the tests (both HW and SW). The computer is only running the test SW.

 

You could have a look at nAN34, which describes production testing using a nRF5-DK as tester. Doing so, you do not need the more expensive tester, but obviously you might not get as detailed results about exact output power, sensitivity etc. but you will get an answer to whether or not the device is funcitonal. Mind though that as you do not have access to the UART lines you can not use our DTM example out of the box, you need to configure it such that it receives the command over the air. At the end, you could do an OTA DFU.

You could implement a RSSI check if you want, just make sure the incoming power is inside the valid range for reading out RSSI. You also need to keep the window wide enough to allow for variation, both because of manufacturing but also from transmission loss if you do not place the DUT in a shielded box. Other than that you should also check that communication with the devices that are connected to the GPIOs is good.

From our perspective this should be enough. Keep in mind that you already paid for a testing all the SoC internals in our production line, you should only test for issues that might be caused by PCBA manufacturing and assembly.

 

Best regards,

Andreas

[jumpingfool]

Thanks Andreas,

I note the DTM example in the SDK is provided as a seperate application which does not use the softdevice. If we want to combine the DTM code with our application to avoid the need to replace the DTM firmware with the application firmware after testing is this possible? If so what steps would we need to take to cleanly transition between the two?

As an aside, in Nordic's real world experience how likely is it that a DUT would "work badly" rather than just not work at all if a manufacturing issue is evident? I'm just trying to qualify the level of risk associated taking a functional approach to testing rather than using an instrument to take measurements. The product is a low cost sensor so if the risk is small then it may make sense for us just to deal with any problems in the field through replacement rather than adding the time/cost for a full DTM test on each unit.

[Andreas]

Hi,

 

Combining the DTM code with your application FW is also an option, especially using nRF52840 that should have enough internal flash for the added code. You just need to add some way to enter the DTM part in your test line. There is no one 'correct' way of doing this, the deciding factor would probably be how you prefer it to work in your test line. One example could be if a pin is pulled either low or high during startup.

 

Most manufacturing issues would probably be noticeable, depending on what the given issue is of course. As an example, a cold solder joint would likely lead to something being non-functional, depending on which solder joint is affected. The radio might still be functional, e.g. if a solder joint in the RF path is affected, though you will see greatly reduced transmitted/received power levels, and thus maximum communication range. Provided you choose components with fair tolerance, there will be slight variation between DUTs but no functional device should 'work badly'. You should not need to run a full DTM test, but you can use the code to set up a test that just sends a couple of packets, test to pass if correct payload is received within a given power range.

 

Best regards,

Andreas