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

USBD and 802.15.4 Power Problem

I previously tried combining USBD CDC ACM with 802.15.4 under Softdevice, and this did not work.

Now I try combining examples/peripheral/peripheral/usbd_cdc_acm with the 802.15.4 stack and NO Softdevice. The result is a compilation error. There appears to be a conflict related to power. Specifically, POWER and NRFX_POWER are needed in the usbd_cdc_acm example, so nrfx_power.c is included in the build. What I observe is shown below. What can be done to correct this? The conflict is because the Makefile specifies nrf_802154_clock_nodrv.c, but this conflicts with nrfx_power.c. Maybe the Makefile should change so that the 802.15.4 stack uses another clock source, I am not sure what.

opt/gccarm/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld: _build/nrf52840_xxaa/nrf_802154_clock_nodrv.c.o: in function `POWER_CLOCK_IRQHandler':
Desktop/nRF52840/SDK15.3/components/802.15.4/src/platform/clock/nrf_802154_clock_nodrv.c:99: multiple definition of `POWER_CLOCK_IRQHandler'; _build/nrf52840_xxaa/nrfx_power.c.o:Desktop/nRF52840/SDK15.3/modules/nrfx/drivers/src/nrfx_power.c:333: first defined here
collect2: error: ld returned 1 exit status

Parents Reply Children
  • Yes, I am using the driver from GitHub. The previous examples for 802.15.4 I had used were working with  nrf_802154_clock_nodrv.c, so I used that as the clock source. I mistakenly thought that using  nrf_802154_clock_sdk.c required Softdevice. So I tried your suggestion to use this SDK clock source, and without Softdevice but with USBD following the CDC ACM peripherals/ example. While initially this failed, some experiments changing values in config/sdk_config.h finally got things to work. 

    I will consider this case closed, since the app now can send and receive 802.15.4 messages as well as send and receive using the USB interface. The initialization part of USB is a bit strange - there appears to be a first phase where the protocol fails (port open, port close) and then a later phase where everything works properly. 

    Thank you Andreas for this suggestion.

Related