Time out error while production test using DTM

[Cimteker]

Hello,

I am testing 9 channels for PER (1,2,3,21,22,23,37,38,39). During testing the last 3 channels I always get a single time out error in response to LE_TEST_END. I also get much higher PER for higher channels (not sure if these 2 problems are related). Anybody with a similar experience? I am using nRF51 dev kit.

Thanks

Jerry

[Edvin]

Hello,

 

During testing the last 3 channels I always get a single time out error in response to LE_TEST_END

 So that is channels 37,38 and 39?

 

I also get much higher PER for higher channels

 And this is 21, 22, 23?

What environment are you testing in? Do you have an RF shielded box, as described in section 3.2 here?

Can you also describe your test setup? Do you use a DK, or an external tester? (MT8852B)

[Cimteker]

Maybe a picture of our dev board will help. It's pretty old, the system was sitting idle for almost 2 years.

[Edvin]

Cimteker said:

Right, but I do not have another DK.

 How many packets are you sending per channel? Can you try to increase it to something like a 1000 packets per channel? And you are probably also generating a report that you are looking at. Can you send the report from a test after you increased the number of packets?

Best regards,

Edvin

[Cimteker]

Thanks Edvin. The timeout issue is gone once I changed the test time to 1000 ms.

I am still dealing with infrequent failures. I even implemented retries but when it fails, it fails 3 times in a row. I am not sure what could be causing this, my DUT is in a shielded RF box so it cannot be an external interference.

[Edvin]

How many packets are you sending on each channel?

[Edvin]

How many packets are you sending on each channel?

[Cimteker]

About 1600. My runtimeinms is 1000 and the length is 10

[Edvin]

Cimteker said:

when it fails, it fails 3 times in a row

 So what exactly is it that fails? Do you loose 3 packets in a row? 

Do you get some sort of log file that is generated when you run the test? If so, can you upload it here? I am struggling a bit to understand what exactly is failing.

[Cimteker]

[Cimteker]

I kept the original limits from the example. 30 % or less is a failure. My script calculates error rate by dividing the number of received packets by the maximum theoretical number (1600 in my case).

You can see from the screenshot provided that channel 37 fails 3 times with 46,47 and 45% error rate.

You can also see in the window below the actual number fo packets received 869,846,880.

I am testing 9 channels: 1,2,3,21,22,23,37,38,39. 

So, in summary, I am getting occasional failures when it fails 3 times in a row. Sometimes the part will fail 2 times in a row and then pass another 100+ times.

The numbers you see in the example provided are with higher attenuation levels so I can show the failures. Normally, when I lower the attenuation, most of the results (error rates) are 0 and then the occasional failure.

[Håkon Alseth]

Hi,

 

This is strange test results.What you could check is that you are using the latest direct_test_mode firmware for the nRF51x22 device, and see if this issue behaves differently if you use the example from SDK v12.3 (path is \nRF5_SDK_12.3.0_d7731ad\examples\dtm\direct_test_mode):

http://developer.nordicsemi.com/nRF5_SDK/nRF5_SDK_v12.x.x/nRF5_SDK_12.3.0_d7731ad.zip

 

This is the latest SDK that has support for nRF51-series devices.

 

Kind regards,

Håkon

[Cimteker]

Thank you Håkon for your suggestion.

Can you point me to documentation describing the process of loading firmware? I joined the project late and the original engineer has left our company.