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
Hi
The build error occurs when the config 'CONFIG_NRF_802154_SL_OPENSOURCE=y' is added. the macro `REQUEST_FUNCTION` (inside nrf_802154_request_direct.c) expects only 1 argument, however inside `nrf_802154_request_csma_ca_start` can be found that the macro is getting 3 arguments: `REQUEST_FUNCTION(nrf_802154_csma_ca_start, p_data, p_metadata);` which seems wrong to me. You can reproduce the error by checking out nrf v1.9.1 and building the openthread coap_server sample with the addition of `CONFIG_NRF_802154_SL_OPENSOURCE=y` in the prj.conf using the following command: `west build -b nrf52840dongle_nrf52840 -p`.
Regards
Matthias
I am able to reproduce this, and it seems to be an issue in the minimal_rcp overlay of the coprocessor as well.
I have informed our developers about this, and will return when I see that is has been fixed or when I find a workaround for this.
Thanks for reporting this
Regards
Sigurd Hellesvik
Thank you
Hi
Do you need CONFIG_NRF_802154_SL_OPENSOURCE for your project, or am you able to work without this configuration?
Regards,
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
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
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
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
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
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
Hi
See nRF Connect for VS Code, 5: Debugging for how to use Ozone Debugging with VS Code
Regards,
Sigurd Hellesvik
