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]

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?

[Håkon Alseth]

Sounds like there's something hanging on either the DUT or the tester-side, that requires a delay between tests. I am sorry, but I cannot say anything more in detail here, as there are components here that are out of scope to the products that we deliver. The python scripts delivered with nAN-034 are developed by us, but once you build a GUI on top, it becomes a lot more complex in terms of whats happening in the chain of communication. I'm not stating that the python scripts are waterproof in all scenarios, but I'm just pointing out the complexity compared to running a 10 line python script for one test.

Has the setup behaved like this before with other devices? If your setup has not been behaving this way with other production runs prior to this, it may point to the firmware running on the DUT misbehaving.

 

Kind regards,

Håkon