This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DTM test not returning any packets

We have the following setup:
 - Both nRF52832 and nRF52840 chips in our product

 - The nRF52832 is a module while the nRF52840 is the chip integrated directly onto our PCB

 - SDK 15.0.0 (and integrating ble_dtm.c into our test firmware)

 -  Our devices communicate quite happily over BLE with each other in all configurations (832-832, 832-840, and 840-840) (relevant a bit later)

We are looking to do certification for our devices and we need to get the packet error rate in a blocking test. I have already looked at nAN34_v1.01 and was planning to retrieve the packet error rate as in the python scripts. As the nRF52 chips are already integrated into our product we have implemented the DTM interface over I2C rather than serial.

The issue we are seeing is that we start the test by setting out of the devices to transmit with the following options followed by running the receiver test for 1-5 seconds before ending the receiver test. When the test is ended the number of received packets is reported as 0:

The transmitter is setup as follows:

- RESET: 0x0000

- Top two bytes in length to 11: 0x010c

- PHY 2M: 0x0208

- TX power -8dBm: 0xb80b

- Start Transmit PRBS9 Max length @ 2442MHz: 0x94fc

The receiver is setup as follows:

- RESET: 0x0000

- Top two bytes in length to 11: 0x010c

- PHY 2M: 0x0208

- Start Receive PRBS9 Max length @ 2442MHz: 0x54fc

- Wait 1-5 seconds

- End Test: 0xc000

For each of the operations ble_dtm.c returns the result as 0, and the ending of the receiver test always returns 32768 which should be packet report: count=0, this is irregardless of the channel selected.

A couple of questions:
1) Is there anything wrong in the setup and commands used?

2) Any Idea why ending any test always returns the packet count as 0?

  • Hi Håkon,

    If you update to a newer ble_dtm, the power-setting bug should be fixed.

    I thought that is probably the case.

    Could you try with another test setup, for instance: channel 2440, 1MBit, 37 bytes payload length?

    I have tried this and the same thing is happening. The TX waking time is faster as you described above due to the shorter packet length, but the RX when performing the test with both a packet length of 37 bytes and 1 byte showed identical results where it would ramp up to RX and then stay disabled returning a packet count of 0

  • Hi,

     

    Alex Crombie said:
    I have tried this and the same thing is happening. The TX waking time is faster as you described above due to the shorter packet length, but the RX when performing the test with both a packet length of 37 bytes and 1 byte showed identical results where it would ramp up to RX and then stay disabled returning a packet count of 0

    Have you tried debugging to see if the NRF_RADIO->TASKS_RXEN in dtm_wait() is continuously called? 

     

    Kind regards,

    Håkon

  • Hi Håkon,

    I have added debugging to dtm_wait() and have also reverted the code to wake up only on events (rather than busy looping) while running the 1M test you proposed.

    I mistakenly used the wrong channel and had the device in RX waking up every so often in the RX state:

    Radio - STATE: 0, MODE: 3, FREQ: 42, TX POWER: 0
    cmd: 1(0x01), freq: 20(0x14), length: 1(01), payload: 0(0x00)
    Ret: 0 Evt: 0
    Radio - STATE: 1, MODE: 3, FREQ: 42, TX POWER: 0
    94474: Radio - STATE: 3, MODE: 3, FREQ: 42, TX POWER: 0
    95000: Radio - STATE: 3, MODE: 3, FREQ: 42, TX POWER: 0
    95500: Radio - STATE: 3, MODE: 3, FREQ: 42, TX POWER: 0
    96500: Radio - STATE: 3, MODE: 3, FREQ: 42, TX POWER: 0
    97500: Radio - STATE: 3, MODE: 3, FREQ: 42, TX POWER: 0
    98000: Radio - STATE: 3, MODE: 3, FREQ: 42, TX POWER: 0
    99000: Radio - STATE: 3, MODE: 3, FREQ: 42, TX POWER: 0
    99477: Radio - STATE: 3, MODE: 3, FREQ: 42, TX POWER: 0
    cmd: 3(0x03), freq: 0(0x00), length: 0(00), payload: 0(0x00)
    Ret: 0 Evt: 32768
    

    However in the case where the channel is correct, the device is waking up periodically in the disabled state.

    cmd: 1(0x01), freq: 19(0x13), length: 1(01), payload: 0(0x00)
    Ret: 0 Evt: 0
    Radio - STATE: 1, MODE: 3, FREQ: 40, TX POWER: 0
    513041: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    513045: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    513046: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    513046: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    513047: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    513048: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    513048: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    513049: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    513050: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    513500: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    514500: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    515000: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    516000: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    517000: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    517500: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    518044: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    518500: Radio - STATE: 0, MODE: 3, FREQ: 40, TX POWER: 0
    cmd: 3(0x03), freq: 0(0x00), length: 0(00), payload: 0(0x00)
    Ret: 0 Evt: 32768
    

    When I first implemented this firmware, I must have missed the need to call dtm_wait(). Having added this to our code it now works correctly.

    Thank you very much for your help and time

Related