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

Direct test mode sample crashes when using LE coded PHY

Hi,

I'm playing around with the Bleutooth DTM sample (https://github.com/nrfconnect/sdk-nrf/tree/master/samples/bluetooth/direct_test_mode) on two nRF52840 boards. The documentation only mentions nRF53 support, but the code seems to have nRF52 support, so i figured i'd give it a try Slight smile

So far it seems to work when using LE 1 Mbps and 2Mbps. However, when using one of the coded PHY's, the receiving board crashes (actually, it just reboots..) as soon as it receives something.

Is this a known limitation?

Thanks,

-Bastiaan

Parents
  • Hi Bastiaan

    Quite a bit has changed between the nRF52 and nRF53, so applications made specifically for one device is not necessarily made for the other.

    The DTM example is rather simple, which is why the 53-version works for nRF52 devices as well, but the Coded PHY layer requires some configuration changes in both cores of the nRF53, which is likely why your application is crashing.

    I suggest you use the nRF5 SDK's DTM example which is specifically made for the nRF52 series and supports all these PHYs by default.

    Best regards,

    Simon

  • Hi Simon,

    Late reply, sorry about that; have been focusing on some other problems.

    I took a look at the nRF5 DTM source; I have the DTM code integrated in our own (nrfconnect based) application; I think integrating the nRF5 code into that would be tricky due to the different API's and such...

    I did do some more debugging on the nrfconnect code: after receiving a packet, something goes wrong with the anomaly 172 workaround code: in dtm.c, dtm_wait_internal(), the following piece of code:

    if (dtm_inst.state == STATE_RECEIVER_TEST &&
          nrf_radio_event_check(NRF_RADIO, NRF_RADIO_EVENT_READY)) {
        nrf_radio_event_clear(NRF_RADIO, NRF_RADIO_EVENT_READY);
    
        if (dtm_inst.anomaly_172_wa_enabled) {
          nrfx_timer_clear(&dtm_inst.anomaly_timer);
          nrfx_timer_enable(&dtm_inst.anomaly_timer);
        }
      }

    The nrfx_timer_enable() call results in an assert:

    ASSERTION FAIL [m_cb[p_instance->instance_id].state == NRFX_DRV_STATE_INITIALIZED] @ WEST_TOPDIR/modules/hal/nordic/nrfx/drivers/src/nrfx_timer.c:150

    If I disable the assert-check in nrfx_timer_enable(), the code runs. Dunno what I'm breaking by doing that, though Slight smile

    I tried to compare this piece with the nRF5 code; it looks similar. Did notice that the nRF5 code lacks the assert-checks the nrfconnect code has.

Reply
  • Hi Simon,

    Late reply, sorry about that; have been focusing on some other problems.

    I took a look at the nRF5 DTM source; I have the DTM code integrated in our own (nrfconnect based) application; I think integrating the nRF5 code into that would be tricky due to the different API's and such...

    I did do some more debugging on the nrfconnect code: after receiving a packet, something goes wrong with the anomaly 172 workaround code: in dtm.c, dtm_wait_internal(), the following piece of code:

    if (dtm_inst.state == STATE_RECEIVER_TEST &&
          nrf_radio_event_check(NRF_RADIO, NRF_RADIO_EVENT_READY)) {
        nrf_radio_event_clear(NRF_RADIO, NRF_RADIO_EVENT_READY);
    
        if (dtm_inst.anomaly_172_wa_enabled) {
          nrfx_timer_clear(&dtm_inst.anomaly_timer);
          nrfx_timer_enable(&dtm_inst.anomaly_timer);
        }
      }

    The nrfx_timer_enable() call results in an assert:

    ASSERTION FAIL [m_cb[p_instance->instance_id].state == NRFX_DRV_STATE_INITIALIZED] @ WEST_TOPDIR/modules/hal/nordic/nrfx/drivers/src/nrfx_timer.c:150

    If I disable the assert-check in nrfx_timer_enable(), the code runs. Dunno what I'm breaking by doing that, though Slight smile

    I tried to compare this piece with the nRF5 code; it looks similar. Did notice that the nRF5 code lacks the assert-checks the nrfconnect code has.

Children
No Data
Related