• State Verified Answer
  • Replies 18 replies
  • Answers 1 answer
  • Subscribers 69 subscribers
  • Views 9026 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 214862
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Liam

Hi,

 For a number of upcoming projects we require 802.15.4 and BLE dynamic multiprotocol support. We need to select a SoC to implement this.

 We like the look of the nrf52840 and see multiprotocol  should be possible using the nRF-IEEE-802.15.4-radio-driver. 

 A number of people have already asked about this but is there an example showing this working yet? Or if someone has got it working would firstly say they've done it and then, maybe, let us have the code ( or even binary ) please?

 We have just had Silicon Labs pull 802.15.4 support from their modules that we were just about to design in so time is critical for us. We don't have the time to learn an API and get to grips with new hardware/software and the inevitable debugging to get to the point deciding to use the nrf52840. If we can prove multiprotocol works we will almost certainly use the nrf52840.

kind regards

Liam

Parents
  • 0

    Hello Liam,

    I don't think we have any examples using the "pure" 802.15.4 driver with BLE, but we have several examples in our Thread and Zigbee SDK using multiprotocol BLE and Thread or ZigBee (which uses the 802.15.4 driver), so yes. It is possible to use the BLE stack (softdevice) together with the softdevice. I know you are not looking for API right now, but we have something called the TimeSlot API, which requests timeslots where you can use the radio as you like, in between the BLE radio events. 

    Thread/ZigBee SDK multiprotocol example:

    ThreadSDK\examples\multiprotocol\ble_thread

    ThreadSDK\examples\multiprotocol\ble_zigbee

    The TimeSlot API is described here. (It is described for SDK11, which is kind of old, but it works on the new SDKs as well, without modifications).

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Hi Edvin,

    Thank you for the reply.

     I've had a look at the Thread and Zigbee SDK. It provides a 802.15.4 radio driver module which seems to provide "raw" access to the 802.15.4 radio but not a "proper" 802.15.4 stack. Most comments on 802.15.4 multiprotocol suggest to use this. To me there would appear to be a considerable amount of work to get the radio driver to the point where it would associate with a 802.15.4 coordinator.

    There seems to be a full 802.15.4 stack provided in SDK 15. It also provides Bluetooth. So would it be possible to use the TimeSlot API to request slots from the Bluetooth side and run the 802.15.4 within them?

    regards

    Liam

  • 0 in reply to Liam

    Hello Liam,

    Yes indeed. That is in fact the method that is used in our multiprotocol examples (where BLE is one of the protocols). The reason for this is that the BLE stack is a very time sensitive protocol, and hence, it will get 1st priority, and the other protocols will run in the timeslots in between. Unfortunately, we don't have an example doing exactly this already, but the TimeSlot API should be quite easy to use, so you should be able to do what you request.

    Best regards,

    Edvin

Reply
  • 0 in reply to Liam

    Hello Liam,

    Yes indeed. That is in fact the method that is used in our multiprotocol examples (where BLE is one of the protocols). The reason for this is that the BLE stack is a very time sensitive protocol, and hence, it will get 1st priority, and the other protocols will run in the timeslots in between. Unfortunately, we don't have an example doing exactly this already, but the TimeSlot API should be quite easy to use, so you should be able to do what you request.

    Best regards,

    Edvin

Children
  • 0 in reply to Edvin

    Hi Edvin,

     I've done a bit of work on this now.

     I have converted our existing code to use the 802.15.4 Stack API present in SDK15.2. Apart from a problem with seeing a coordinator beacon payload this now works as a endpoint and connects to our existing 802.15.4 coordinator.

     Secondly, using the BLE template from SDK15.2 I have implemented the timeslot API. I think this is working. A LED on the DK is being switched on and off by cases NRF_RADIO_CALLBACK_SIGNAL_TYPE_START and NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 in nrf_radio_signal_callback_return_param_t.

     So I now want to merge the two. So could you confirm that on NRF_RADIO_CALLBACK_SIGNAL_TYPE_START I should start calling the IEEE 15.4 handler and stop on NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 . 

     Do I need to worry about the state of the IEEE stack between timeslots i.e. is it preserved? Do I have to restore the radio state (channel, power etc) at any point or does the timeslot API take care of it?

     When should I initialise the IEEE stack?

     Sorry for all the questions; I just want to make sure I'm taking the right approach.

    kind regards

    Liam

  • 0 in reply to Liam

    That is correct. From NRF_RADIO_CALLBACK_SIGNAL_TYPE_START you have control of the radio, and NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 is the callback called before the BLE event, and this is where you should gracefully shut down what you are doing in order to pass the radio over to the SoftDevice.

    "Do I need to worry about the state of the IEEE stack between timeslots"?

    This depends on how it is set up. I haven't looked too much into the 802.15.4 stack. By the look of the SDK15.2.0\examples\802.15.4\wireless_uart example, it looks like the state of this would be saved, and doesn't need to be set up at every timeslot. I guess you will find out quite fast whether or not it is saved between the timeslots.

    You can initialize the IEEE at any time, but when you require the radio, it must either be in a timeslot, or before you use the softdevice.

    Best regards,

    Edvin

  • 0 in reply to Edvin

    I've had a go at getting this working today.

    Starting with my timeslots BLE template, I have combined it with my 802.15.4 example. I have compiled it and have got it to run.

     When I call sys_init (of system abstraction layer in the 802.15.4) I get an error:

    <error> app: SOFTDEVICE: INVALID ADDRESS MEMORY ACCESS

    The reported address is 0x2000.

    Any ideas? I have not really got past initialisation. Do I have to use the system abstraction layer to use 802.15.4? 

    kind regards

    Liam

  • 0 in reply to Liam

    Hello,

    The sys_init function uses the parameters from your IDE settings. I don't know what IDE you use, but in Segger Embedded Studio, it looks like this:

    In Keil it is found under project settings->Target->Read/Write Memory Areas.

    If you look at the project files for BLE vs. non BLE examples, that is, examples using the softdevice or not, there are different settings. The exact settings depends on your BLE application, but take these project settings from one of the BLE examples for the nRF52840, and copy them into your project. If you need to adjust these, it should be printed in the log (NRF_LOG) when the application starts.

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Hi Edvin,

    I am using Segger.

    I based my project on the SDK15 ble_template so the IDE settings are as there were originally set in this . As a test I transferred the values from the IEEE15.4 example and it stopped working altogether. Beyond that I do not know what settings to try.

    Can you confirm that multi protocol will actually work. I've found another post

    https://devzone.nordicsemi.com/f/nordic-q-a/36814/nrf52840-multiprotocol-ble-802-15-4-without-zboss/141729#141729

    It says "The 802.15.4 implementation in the regular SDK do not have the dynamic multiprotocol support that the Thread and Zigbee solutions have." 

    Its the regular SDK that I am trying to use.

    kind regards

    Liam

Related