• State Not Answered
  • Replies 11 replies
  • Subscribers 63 subscribers
  • Views 1134 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289270
Options

Nrf v1.9.1 Openthread application not building: nrfxlib/nrf_802154/driver/src/nrf_802154_request_direct.c:196:66: error: macro "REQUEST_FUNCTION" passed 3 arguments, but takes just 1

Matthias_A

Hi

I am bumping my NRF Connect SDK application to nrf v1.9.1. However, I am getting the following error: `nrfxlib/nrf_802154/driver/src/nrf_802154_request_direct.c:196:66: error: macro "REQUEST_FUNCTION" passed 3 arguments, but takes just 1`. Could it be that `REQUEST_FUNCTION(nrf_802154_csma_ca_start, p_data, p_metadata);` should be replaced by `REQUEST_FUNCTION_PARMS(nrf_802154_csma_ca_start, p_data, p_metadata);'?

Thanks in advance

Matthias

Parents Reply Children
  • 0 in reply to Sigurd Hellesvik

    Hi

    Since debugging is not possible while CONFIG_MPSL is enabled, I do have to enable CONFIG_NRF_802154_SL_OPENSOURCE. If not, CONFIG_MPSL is enabled automatically. Is it not correct to replace REQUEST_FUNCTION with REQUEST_FUNCTION_PARMS? 

    Regards,

    Matthias

  • 0 in reply to Matthias_A

    Hi

    I were unsure about this, so I asked our developers about the issue.

    They say that while CONFIG_NRF_802154_SL_OPENSOURCE have worked fine with Thread 1.1, the opensource drivers does not support CSL, which is required for Thread 1.2.

    And with Thread, certification is important. Even if you are able to change our SDK to use the opensource drivers, it would not be certified then.

    Because of this, we recommend that you do not use CONFIG_NRF_802154_SL_OPENSOURCE, but rather disable CONFIG_MPSL another way.
    Have you tried disabling it manually, by setting CONFIG_MPSL=n?

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    Hi

    So that means CONFIG_NRF_802154_SL_OPENSOURCE is deprecated as from Thread 1.2, however the update that introduces the build error dates from the 7th of February.

    If I understand well, a device that uses the opensource drivers is NOT Thread certified?

    Disabling CONFIG_MPSL does seem te work only if I set CONFIG_NRF_802154_SL_OPENSOURCE=y. If I don't add CONFIG_NRF_802154_SL_OPENSOURCE, I get the following warning: 

    warning: MPSL (defined at /home/user/beam-project/nrfxlib/mpsl/Kconfig:7) was assigned
    the value 'n' but got the value 'y'

    I was using CONFIG_NRF_802154_SL_OPENSOURCE=y only for debugging since using breakpoints when CONFIG_MPSL is enabled, is not possible. That is the only reason why I would use CONFIG_NRF_802154_SL_OPENSOURCE.

    Regards

    Matthias

  • 0 in reply to Matthias_A

    Hi

    Matthias_A said:
    If I understand well, a device that uses the opensource drivers is NOT Thread certified?

    Nordic has a set of pre-certified Openthread libraries, which you can use to have an easier time getting a Thread Certification for your product.

    If you use the opensource drivers, these libraries are not Thread 1.2 certified.
    You could likely still work with Thread to get your whole project Thread Certified even with the opensource drivers, but it would be a lot more work.

    For MPSL: Are you using multiple protocols at once?
    If so, this is likely the case that you need to have this enabled.

    Does the answer in case 82300 help you debug while using MPSL?

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    Hi

    I am using only 1 protocol at once, that is Openthread. I am building with Zephyr and debugging in VSCode environment. It seems that the solution is only applicable for Ozone and SES.

    Regards
    Matthias

Related