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.

[Håkon Alseth]

It does indeed look like you're using the default pins.

You drag the file "\nRF5_SDK_12.3.0_d7731ad\examples\dtm\direct_test_mode\hex\direct_test_mode_pca10028.hex" to the mass storage device labeled "J-LINK" and that's it. It should boot up within seconds. You can power cycle if you'd like, but wait atleast 4-5 seconds after drag-and-dropping the .hex file.

 

Kind regards,

Håkon

[Cimteker]

Thank you Håkon,

What is the difference between pca10028.hex and pca10028_s130.hex files?

[Håkon Alseth]

the one's marked _s130.hex expect that the softdevice is loaded into the device, meaning; the application is offset in flash and RAM.

[Cimteker]

Thank you Håkon,

I have the latest firmware running now. There's still this problem with occasional failure. 1-2% of the time it will read one of the channels very high ( >40%). I am struggling to explain this. Any ideas?

[Håkon Alseth]

That is strange. How does your test setup handle the nRF between tests? Are you powering the device down and up again, or are you sending LE_TEST_END then starting a new one?

Have you tried replacing the kit in the tester to see if this has any impact on the problem?

 

Kind regards,

Håkon

[Cimteker]

Hi Håkon, thanks for your reply.

I use LE_TEST_END for each channel, the power for the dev kit is not cycled during testing.

I do not have another dev kit to try. It ran overnight with 1400 cycles and 4 failures so that's not bad, but still. 

[Håkon Alseth]

Do you have a nRF52 kit for instance? It would be interesting to see if this issue still occurs on other devices as well.

Could be a problem with the UART handling, where the firmware gets a framing error or similar. The default behavior for the nRF dtm firmware is to assert (softreset) if this happens. Have you tried with a different USB-UART bridge?

Kind regards,

Håkon

[Cimteker]

Hi Håkon, thanks for your reply.

We do not have any other hardware. We're a system integration house, we only buy what we need to complete the project, no spares.

I think my communication is ok. I do get occasional timeouts on the DUT side, but I do not know what firmware they are running. 

Here's a rough sketch of what our system looks like, hopefully, this will give you a better idea. 

[Håkon Alseth]

Looking through the code, there is a theoretical chance that this is related to receiving a framing error on the nRF-side, and if you are running based on the python scripts in nAN-034, these will not retry commands by default. However, if this was the case, the result should be a timeout on the command itself, not a high packet error.

Are these issues only observed when testing against one specific DUT, or is this something that you have seen on other products as well?

 

Kind regards,

Håkon

[Cimteker]

Thanks Håkon for your response.

All product samples exhibit this behavior, I have 10 samples.

Could please make some comment about timing for this test? Do I need to wait between switching channels? I found that having 300-500 ms there helps. There was also another delay absolutely needed to make it work. Here's where I inserted it:

- Start transmitting on the requested channel (i.e dev kit)

- Receive packets for 100 ms (DUT)

- Wait 0.5 sec

- Stop Transmitting on the requested channel (dev kit)

Without this 0.5 second delay, it would not work. We'd be getting exceptions, meaning no response to LE_TEST_END command.

If I increase the receiving window to 1 s (from 100 ms), this 0.5 delay is not necessary.

Is there an explanation for it?