UARTE0_UART0_IRQHandler defined in 802_15_4_lib_keil.lib

I'm trying to add 802.15.4 driver into my project (to implement an proprietary protocol).

The wireless_uart sample is very helpful and I got it up and running.

However, after adding the 802_15_4_lib_keil.lib into my main project, I got this link error:

Error: L6200E: Symbol UARTE0_UART0_IRQHandler multiply defined (by nrf_drv_uart.o and nrfx_prs.o).

It seems like the 802_15_4_lib_keil.lib includes nrf_drv_uart.o, and compiled without PRS support? Any way to workaround this?

Parents
  • Hi,

    In the documentation of the 802.15.4 driver the following is stated:

    While working with the 802.15.4 MAC library, you cannot use the following peripherals in your application as they are exclusively used by the library:

    • RADIO
    • TIMER0
    • RTC0
    • UART0

    If you change to using another UART instance than UART0 in your project the library should compile with PRS.

    Anyways, be also aware that it is recommended to use the nRF IEEE 802.15.4 radio driver in NCS if you are currently developing a new product.

    Take a look at the nRF Connect SDK and nRF5 SDK statement for more information about the migration to the nRF Connect SDK.

    Best regards,

    Marjeris

  • Thanks for the reply, I do aware the existence of NCS. However, the other parts of our project rely on FreeRTOS(cmsis-os api), to my understanding, our only option is using nRF5 SDK.

    I hacked a little by not including some of .o inside the library and got it working. But got stuck at making dynamic multi-protocol working.

    To be honest, the whole nRF SDK family is very confusing…. I’ve tried the following ways, and I got different mileages for each of them… 

    1. Using the 802.15.4 files inside nRF SDK, I got tx/rx working, but not with softdevice, not dynamic multi-protocol.

    2. Download old version (1.10)of 802.15.4 radio driver form github

    3. Use 802.15.4 driver from “nRF SDK for zhigbee and thread” , this SDK seems older, somehow I failed to download the image into the board(PCA10100 DK).

    to get dynamic multi protocol working nRF SDK, what’s the best route in your opinion? My next attempt maybe copy the files and libraries from "nRF SDK for zhigbee and thread", which has multiprotocol support. into an nRF5 SDK project and see how it goes...

  • Hi,

    There is no multiprotocol support for the 15.4 library used in the wireless_uart example. If you need multiprotocol for your application then you need to use the newer nRF 802.15.4 driver from github and look for the older versions that are used with the nRF5 SDK for Thread and Zigbee.

    Are you planning on implementing a propietary solution using the 802.15.4 protocol? Do you know if you will need a MAC layer? The nRF 802.15.4 driver from github does not include a MAC layer so you will need to implement this yourself if needed...

    Best regards,

    Marjeris

  • Hi, 

    I got the 1.6.1 version of the nRF 802.15.4 driver from github compiled and running on my PCA10100 board. I need it working with BLE so I was trying to use the softdevice config, it was quite bumpy to set it up (lots of macro tweaking and digging) and I still cannot send a packet.

    Is there any example for my configuration? BLE + 802.15.4 using the git hub driver? BTW I don't need the MAC layer, so a very simple one that transmit/receive raw packages should be fine.

  • Hi,

    One example for this is how the nRF 802.15.4 driver is integrated for nRF5 SDK for Thread and Zigbee v4.1.0. There are some multiprotocol limitations listed in the release notes:

    - Because of limitations of simultaneous operation of the SoftDevice frontend and the 802.15.4 frontend:
      - Do not use the PPI channels reserved by the SoftDevice (17, 18, 19).
      - The SoftDevice and the 802.15.4 driver must use separate sets of PPI channels, for example (1, 2) and (3, 4).
      - The SoftDevice and the 802.15.4 driver must use separate sets of GPIOTE channels, for example 4 and (5, 6, 7).
    - Due to a limitation of the SoftDevice, depending on the configured timeslot timeout of the nRF IEEE 802.15.4 radio driver, BLE activity may cause 100% CPU utilization or increase switching times.
  • Thanks for your reply! I got it partially working... but still not "dynamic"...

    By calling function nrf_raal_softdevice_config(), I got 802.15.4 sending and receiving working with SoftDevice.

    However, after I start BLE advertising, 802.15.4 packets no longer show up.

    I've checked the PPI channels of SD and 802.15.4 driver (all with default settings)

    PPI for softdevice from file "nrf_soc,h" are 17-31, and group 4 & 5

    PPI for radio driver from file "nrf_802154_peripherals.h" are 6-14, and group 0 & 1

    Not sure where to check GPIOTE settings, it seems like radio driver does not using any GPIOTE by default?

    I checked normally the RX events come from SWI3, but after BLE advertising starts, the SWI never triggers...

Reply
  • Thanks for your reply! I got it partially working... but still not "dynamic"...

    By calling function nrf_raal_softdevice_config(), I got 802.15.4 sending and receiving working with SoftDevice.

    However, after I start BLE advertising, 802.15.4 packets no longer show up.

    I've checked the PPI channels of SD and 802.15.4 driver (all with default settings)

    PPI for softdevice from file "nrf_soc,h" are 17-31, and group 4 & 5

    PPI for radio driver from file "nrf_802154_peripherals.h" are 6-14, and group 0 & 1

    Not sure where to check GPIOTE settings, it seems like radio driver does not using any GPIOTE by default?

    I checked normally the RX events come from SWI3, but after BLE advertising starts, the SWI never triggers...

Children
Related