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

[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?