• State Verified Answer
  • Replies 2 replies
  • Subscribers 89 subscribers
  • Views 812 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 263909
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Debugging issues with single core architecture a thing from the past with nRF5340

daubsi

Dear Nordic Team,

I am considering to get a nRF5340-DK after having read that this is now a multicore design. For the nRF52832 debugging an app was often difficult because of the realtime timing issues of the softdevice, e.g. the SD asserts if a breakpoint was hit in reaction to a SD function call, etc..

I would like to inquiry if these restrictions still exist with the nRF53. I know from a competitor product which follows the same design, that it is no problem bp'ing anywhere in code without any issues due to the "mailbox" design between the RF/SD/BLE and the APP processor. 

Is this here now similar with that new architecture?

Thanks!

Parents
  • +1

    Hi,

    Is this here now similar with that new architecture?

     With 2 cores there are multiple ways/architecture splits that can be done. In our nRF Connect SDK the default nRF53 BLE architecture, and the architecture that is fully supported today looks like this:

    It's explained in this video, www.youtube.com/watch

    Here the Bluetooth LE Controller runs on the network core, and the Bluetooth LE Host runs on the application core. Let's say that you are connected to another BLE device, and you are not doing any GATT write/reads, control procedures, etc. I.e. only Empty PDUs are sent by the Controller every connection interval. Then you can set breakpoints and halt the application core, and the network core will still keep the BLE connection alive by sending these Empty PDUs. Let's say the nRF5340 is a peripheral/GATT server, and is the only one that is sending data(e.g. sending indications or notifications), then you can set breakpoints, and the link will be still be alive. But, if the other BLE device(e.g. a phone that is a central/GATT client) tries to do a GATT write/read, then the Bluetooth Host on the application core is needed to respond to that, and then you have 30 seconds(defined in the BLE spec) to send the response before the operation timeouts, and most BLE devices will then disconnect if such a timeout happens. I.e. in this scenario you only have up to 30 seconds you can halt the application core.

    Other architectures are possible, you could run both Bluetooth Host and Controller on the network core, and use some kind of serialization protocol between your application on the application core, and the Bluetooth Host on the network core, allowing you to set breakpoints in the application core for prolonged time, also when the other BLE device is sending data as well.

    I hope this clarified things.

    BR,

    Sigurd

Reply
  • +1

    Hi,

    Is this here now similar with that new architecture?

     With 2 cores there are multiple ways/architecture splits that can be done. In our nRF Connect SDK the default nRF53 BLE architecture, and the architecture that is fully supported today looks like this:

    It's explained in this video, www.youtube.com/watch

    Here the Bluetooth LE Controller runs on the network core, and the Bluetooth LE Host runs on the application core. Let's say that you are connected to another BLE device, and you are not doing any GATT write/reads, control procedures, etc. I.e. only Empty PDUs are sent by the Controller every connection interval. Then you can set breakpoints and halt the application core, and the network core will still keep the BLE connection alive by sending these Empty PDUs. Let's say the nRF5340 is a peripheral/GATT server, and is the only one that is sending data(e.g. sending indications or notifications), then you can set breakpoints, and the link will be still be alive. But, if the other BLE device(e.g. a phone that is a central/GATT client) tries to do a GATT write/read, then the Bluetooth Host on the application core is needed to respond to that, and then you have 30 seconds(defined in the BLE spec) to send the response before the operation timeouts, and most BLE devices will then disconnect if such a timeout happens. I.e. in this scenario you only have up to 30 seconds you can halt the application core.

    Other architectures are possible, you could run both Bluetooth Host and Controller on the network core, and use some kind of serialization protocol between your application on the application core, and the Bluetooth Host on the network core, allowing you to set breakpoints in the application core for prolonged time, also when the other BLE device is sending data as well.

    I hope this clarified things.

    BR,

    Sigurd

Children
Related