• State Verified Answer
  • Replies 3 replies
  • Subscribers 69 subscribers
  • Views 273 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 334515
Options

Interface/Communication between the Nordic BLE chip and the other Main MCU(Ex:- Stm32 or TI)

Teja_K

Hello Nordic,

We are currently working on a project that involves communication between Main MCU and a Nordic BLE.  From the documents i found that, we can use SPI or UART for communication, and I would appreciate any advice on the best way to structure the protocol for smooth data transfer between the two MCUs.

Additionally, I would like to understand how the main MCU can send data to the Nordic BLE MCU, update the advertising data or parameters during read/write requests from BLE, and, most importantly, how to manage firmware updates in this setup. What would be the recommended approach for performing firmware updates for the Nordic BLE MCU via Main MCU?

May be any block diagram or technical design already available, please let me know.

Thanks & Regards

Teja

  • 0

    Hi Teja, 
    Could you give some more information about your application  ?
    How do you plan to allocate the BLE stack ? How much should the main MCU handle with regard BLE ? 
    Do you plan to leave all BLE activity on the nRF52 chip and only do some proprietary command from the main MCU to start advertising for example ? Or you plan to have the BLE APIs to be called from the main MCU ?

    You can use any protocol to communicate between the nRF52 and the main MCU for example SPI, UART, I2C. We have samples in the nRF Connect SDK that show how you can use the peripherals. There isn't a standard protocol that you should use. For controlling the nRF52 from an external chip, I would suggest to take a look at the shell protocol: 

    https://docs.zephyrproject.org/latest/services/shell/index.html

    Here is an example doing shell bluetooth from uart :  Using Bluetooth Shell

    Regarding your question about DFU, could you tell more on how you plan to receive the image ? Are you receiving image from BLE or from other means (e.g Wifi ) ? It's flexible on how you do DFU update on the nRF52, as long as you copy the new image to the correct location, the bootloader (MCUBoot) will handle the swapping. 

  • 0 in reply to Hung Bui

    Hi Hung,

    Thanks for the response.

    Here are more details as per the request:

    Could you give some more information about your application  ?

    - Our application consists of a sensor connected to the Main MCU, which reads the data and then send it to the BLE Nordic chip to communicate with Mobile.

    Do you plan to leave all BLE activity on the nRF52 chip and only do some proprietary command from the main MCU to start advertising for example ? Or you plan to have the BLE APIs to be called from the main MCU ?

    - Our initial idea is to run ble activity completely on the nRF52 chip and send some commands for configuration, start advertising. But we dont know, how data can be exchanged in this scenario between them and how to get the response back from nRF chip to Main MCU.

    Because of these drawbacks, we planned to have some APIs to be called from the main MCU. so when we change the MCU, we can use this API for communicating with the BLE Chip.

    From Design perspective, What would be the better approach?

    How do you plan to allocate the BLE stack ? How much should the main MCU handle with regard BLE ? 

    - I did not understand the question, could you please describe this in more detail. 

    Please correct me if am wrong, The Main MCU should handle the response data packets that are received from the BLE chip and also if possible the firmware update.

    Are you receiving image from BLE or from other means (e.g Wifi ) ? 

    - We would like to receive the image from the BLE and this new image received should be transferred to the main mcu and from there the firmware update for both the chips need to be done. This is our idea. is it possible?

    If you need more information or any details, we can also have a short call for further discussion.

    Thanks & Regards

    Teja

  • +1 in reply to Teja_K

    Hi Teja, 

     I think you would need to do your study and decide on your own what suit you the best. 
    The options you have, as far as I can see, is: 

    #1 - The nRF52 run almost independent, the BLE communication will be converted to proprietary command/data sending over UART to main MCU.

    #2 - The nRF52 is partly independent, it support shell communication that the main MCU can send BLE command and receive BLE data via shell
    https://docs.zephyrproject.org/latest/services/shell/index.html
    Using Bluetooth Shell

    #3 - The nRF52 is a connectivity chip, all BLE API is called from the main MCU and use RPC protocol communicate between the 2 chips:
     https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/libraries/bluetooth_services/rpc.html
    https://docs.nordicsemi.com/bundle/ncs-2.3.0/page/nrfxlib/nrf_rpc/README.html

    Depends on the protocol you choose, the DFU mechanism will need to adapt accordingly. However, if you want to handle the DFU from the main MCU,  the approach is to send the image(s) to the main MCU. The main MCU then use serial DFU to update the connectivity chip. 

    Teja_K said:

    How do you plan to allocate the BLE stack ? How much should the main MCU handle with regard BLE ? 

    - I did not understand the question, could you please describe this in more detail. 

    Bluetooth stack implementation in our SDK is split into host (high level) and controller (low level), there is option to run the high level stack on the main MCU and the low level stack on the nRF52. Then you would need to use HCI protocol to communicate between them. If you are not familiar with this, I would suggest to stick to the 3 options above. 

Related