• State Verified Answer
  • Replies 13 replies
  • Subscribers 76 subscribers
  • Views 2195 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 311673
Options

nRF5340 ESB OTA

Domziy

Hello,

I have tested the smp_svr with hci_rpmsg Bluetooth OTA feature and I have successfully uploaded the firmware which worked with the old device manager Android app. I would like to use 2 nrf5340 with ESB protocol. What would be a good starting point do I use the hci_rpmsg existing code and enable ESB and configure it as such or is it better to use bootloader UART code? I am a bit stuck as the hci_rpmsg sample code is dependent on bluetooth defines and ESB and bluetooth give an error message when both are enabled. So if you could give me some guidance on the right decision and how I should handle the problem. Thank you

I am using:
2x NRF5340 DK 
nRF Connect for desktop v4.1.2
nRF Connect SDK v2.4.0

Parents
  • 0

    Hi Domen

    The IPC service and its API is well described in the Zephyr project documentation here, and you can either use the IPC service shell transport or IPC UART driver to send data over UART to another processor. Let me know if you run into any problems.

    Best regards,

    Simon

  • 0 in reply to Simonr

    Hello Simon,

    I see, thank you for the references. With the smp_svr sample and included hci_rpmsg the hci_rpmsg opens up the IPC service like how it is described in the .dts file on the shared memory. From what I understand some task in the application core opens the same instance and they start communicating through that medium. The application task that communicates through IPC I assume is writing to flash. But the packets are formed in a certain way so that the task knows if that is for being written to flash or any other commands based on the packet. In the smp_svr main.c there isn't anything that shows opening any IPC service so I assume the task is initialized prior with the configs and runs in the back. When I list the tasks the kernel can show it looks like this:

    Looking into mcumgr smp in your github under nrfconnect/sdk-zephyr/subsys/mgmt/mcumgr/mgmt/src/mgmt.c I thought that is the task that communicates with the network core and flashes things but looks like some other task is responsible for that. Now my question is which task/thread/project in this sample project is writing to the flash with the information from the network core? And if you maybe have documentation or API on how this packets are structured for the app IPC task to write to flash. From the log of what is send to the ipc_service_send function in the hci_rpmsg you get information like this:

    And it looks like there is a structure behind the data packets with commands infront with the following data. I would then structure the same packets from the information that I get from ESB and send it through the same IPC process. 

    Best regards,

    Domen

Reply
  • 0 in reply to Simonr

    Hello Simon,

    I see, thank you for the references. With the smp_svr sample and included hci_rpmsg the hci_rpmsg opens up the IPC service like how it is described in the .dts file on the shared memory. From what I understand some task in the application core opens the same instance and they start communicating through that medium. The application task that communicates through IPC I assume is writing to flash. But the packets are formed in a certain way so that the task knows if that is for being written to flash or any other commands based on the packet. In the smp_svr main.c there isn't anything that shows opening any IPC service so I assume the task is initialized prior with the configs and runs in the back. When I list the tasks the kernel can show it looks like this:

    Looking into mcumgr smp in your github under nrfconnect/sdk-zephyr/subsys/mgmt/mcumgr/mgmt/src/mgmt.c I thought that is the task that communicates with the network core and flashes things but looks like some other task is responsible for that. Now my question is which task/thread/project in this sample project is writing to the flash with the information from the network core? And if you maybe have documentation or API on how this packets are structured for the app IPC task to write to flash. From the log of what is send to the ipc_service_send function in the hci_rpmsg you get information like this:

    And it looks like there is a structure behind the data packets with commands infront with the following data. I would then structure the same packets from the information that I get from ESB and send it through the same IPC process. 

    Best regards,

    Domen

Children
No Data
Related
Terms of service