SPI & Bluetooth best practices

RE: SPI & Bluetooth best practices

ryerye120 — Thu, 21 Oct 2021 21:29:51 GMT

Karl!

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/335221#335221"]Great! Please do not hesitate to open another ticket about it if you encounter any issues. The sniffer will make it easy to spot any bottlenecks in your throughput, or other unintended slow-downs.[/quote]

Yea sorry for having this ticket spiral out of control - luckily it looks like we may have solved my issues.

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/335221#335221"]The SoftDevice will need to be allocated enough FLASH and RAM to be able to meet its configured operation. So, if you increase the buffer sizes, or number of concurrent connections, etc. the SoftDevice may need to be allocated more resources.[/quote]

This makes a lot of sense. I'll keep an eye out for any more RAM warnings. I actually updated the memory allocation to satisfy my larger MTU - that last increase may have given me enough space for my latest updates.

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/335221#335221"]I would rather recommend that you make an estimate for how many notifications that may be queued in a single connection interval, and increase this to account for possible retransmissions (alternatively you could implement specific error handling for the NRF_ERROR_RESOURCES that buffers the notification for later retransmitting).[/quote]

What I ended up doing was calculating how many notifications I expect to have in 7.5ms ( ~8), rounded that up to 10, and then tripled it. Does that seem fair?

Right now things seem to be working. I'd like to rubber ducky/walk through my fixes. Hopefully, you'll be able to point out anything seriously wrong in my thought process and if not, others will be able to see my full debrief and learn from it.

Ultimately my problem was that I was unable to send data over bluetooth as fast as I wanted. My 1Mbps spec is well within BLE5's capabilities but my code wasn't up to snuff. To achieve a demo of what will eventually be a full 1Mbps SPI <-> BLE <-> USB link, I had to make a few distinct changes. I started with the ble_app_uart peripheral example.

First I had to make sure my peripheral and central devices were operating in the 2M PHY mode. To achieve this I put in an option to run the following block of code after my link was established:

  ble_gap_phys_t const phys =
  {
      .rx_phys = BLE_GAP_PHY_2MBPS,
      .tx_phys = BLE_GAP_PHY_2MBPS,
  };
  err_code = sd_ble_gap_phy_update(m_conn_handle, &phys);
  APP_ERROR_CHECK(err_code);

To avoid weird specifics, let's just say that every time I click one of my dev kit's buttons, this block is run.

Second, I had to increase my notification queue size. This was a little tricky because I'm not that good yet following SDKs, but thanks to Karl's help I was able to figure out where to actually increase my queue size without breaking anything. In ble_stack_init(), there's a function called nrf_sdh_ble_default_cfg_set(). This function helps set certain ble_stack parameters, the MTU, number of links, etc. By default it doesn't update your notification queue size, but you can. Inside nrf_sdh_ble.c, there exists nrf_sdh_ble_default_cfg_set(). I added the below block at the end of the function. After the fact I foung this thread which discusses a similar fix - the OP in that thread was kind of an *** though.

    ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size = 30;
    ret_code = sd_ble_cfg_set(BLE_CONN_CFG_GATTS, &ble_cfg, *p_ram_start);
    if (ret_code != NRF_SUCCESS)
    {
        NRF_LOG_ERROR("sd_ble_cfg_set() returned %s when attempting to set BLE_CONN_CFG_GATTS.", nrf_strerror_get(ret_code));
    }

These two fixes helped me push my BLE transfers to run faster and without breaking but I still wasn't able to run everything as fast as I wanted. The final puzzle piece dawned on me when re-reading something Karl said:

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/335221#335221"]The highest throughput is not achieved with 7.5 ms a connection interval, but rather with a longer one where you send multiple maximum-length packets.
This increases the throughput by reducing the number of bytes lost to overhead.[/quote]

While I have kept a small connection interval, it occurred to me that I wasn't maximizing how much data I was sending at once. In order to minimize overhead, it's advantageous to pack as many of your samples as possible into a single BLE packet. Due to the nature of my system, I can pack three packets into a maximally sized BLE packet (MTU = 251). Once I implemented this, my code was running without hitting any NRF lack_of_resource errors!

I am running into some errors on the RX side of my link but that's for another thread!

Hopefully this helps others - Karl, thank you so much for all of your help!

RE: SPI & Bluetooth best practices

Karl Ylvisaker — Thu, 21 Oct 2021 08:44:08 GMT

Hello again Ryan,

[quote user="ryerye120"]As always, thank you for your patience and help! I realize a lot of these are basic questions - I can't describe how appreciative I am of your time/effort.[/quote]

I am glad to hear you say that, and happy to hear that you have found my comments helpful to your project!

[quote user="ryerye120"]EDIT: sorry for the double post, I accidentally 'replied' to the wrong message so I copied my response to here so it's easier for you/others to follow.[/quote]

No need to apologize - thank you for editing it to make it easier to follow for both me and others!

[quote user="ryerye120"]I'm using an nrf52 dongle that's acting like a BLE<->USB pipe. I built this based off of the ble_uart_c example and took stuff from the usbd_ble_uart peripheral when needed. [/quote]

This is a good way to go about implementing this.

[quote user="ryerye120"]I've heard of it but haven't used it - I'll order another dev kit and set a sniffer up! I completely forgot this was a thing.[/quote]

Great! Please do not hesitate to open another ticket about it if you encounter any issues. The sniffer will make it easy to spot any bottlenecks in your throughput, or other unintended slow-downs.

[quote user="ryerye120"]Oh you were spot on - I added it to the release build config. This time I added it to the projects common build config and I'm getting a proper error out now.[/quote]

This is a common occurrence, no worries! The proper error logs are very helpful in debugging any driver related issues.

[quote user="ryerye120"]"Too many notifications queued." For that user it seems to have boiled down to their notification queue being too small[/quote]

This is the most common reason for the NRF_ERROR_RESOURCES error code being returned from sd_ble_gatts_hvx - queueing notifications faster than they are being sent. Increasing the queue size will only solve the root cause in the case that the queue is too small to hold all the notifications that will be queued each connection interval, and all queued notifications are being sent each connection event.
Usually, one would additionally have to look at increasing the number of notifications sent per connection event. This could be done by increasing the MTU size, using a different PHY, and increasing the connection event length so that multiple notifications may be sent each connection event.

[quote user="ryerye120"]The linked thread implies that this queue size is part of the BLE stack. If that's the case the BLE 'stack' includes not just the BLE drivers but also the memory interface between the CPU & the drivers. Is that right? [/quote]

The SoftDevice will need to be allocated enough FLASH and RAM to be able to meet its configured operation. So, if you increase the buffer sizes, or number of concurrent connections, etc. the SoftDevice may need to be allocated more resources.

[quote user="ryerye120"]Firstly, is there a max queue size? Ideally i'd just set it to the max using sd_ble_cfg_set() - BUT I can't find a single reference to sd_ble_cfg_set() in the existing solution. Do you have any pointers to where I may be able to find an example so I can safely call sd_ble_cfg_set() with a new queue size?[/quote]

I would rather recommend that you make an estimate for how many notifications that may be queued in a single connection interval, and increase this to account for possible retransmissions (alternatively you could implement specific error handling for the NRF_ERROR_RESOURCES that buffers the notification for later retransmitting).
sd_ble_cfg_set may be called at any time when the SoftDevice is enabled, as long as the BLE part of the SoftDevice is not yet enabled. Please see the note in the sd_ble_cfg_set API reference for more information about this.

[quote user="ryerye120"]Now, assuming I get that set, in order to maximize my throughput, I can set my connection interval to as small as possible (7.5ms, right?), maximize my MTU (to 251, right?), set my PHY to 2M, and then set my total number of links to just 1 (so that I don't have to share bandwidth).[/quote]

This depends on whether latency is more important than throughput.
The highest throughput is not achieved with 7.5 ms a connection interval, but rather with a longer one where you send multiple maximum-length packets.
This increases the throughput by reducing the number of bytes lost to overhead.
You could see the exact numbers for the difference here in the throughput documentation I referenced earlier.
The increased latency might not be worth it for certain applications, and you can of course still achieve a good throughput using the 7.5 ms connection interval (parameters also specified in the throughput documentation).

Best regards,
Karl

RE: SPI & Bluetooth best practices

ryerye120 — Thu, 21 Oct 2021 04:15:55 GMT

EDIT: sorry for the double post, I accidentally 'replied' to the wrong message so I copied my response to here so it's easier for you/others to follow.

Hi Karl,

Karl Ylvisaker said:

What are you currently using as your central?

I'm using an nrf52 dongle that's acting like a BLE<->USB pipe. I built this based off of the ble_uart_c example and took stuff from the usbd_ble_uart peripheral when needed.

Karl Ylvisaker said:

The best tool for debugging connectivity and throughput issues is the nRF Sniffer tool which lets you monitor on-air BLE traffic. Are you familiar with this tool already?

I've heard of it but haven't used it - I'll order another dev kit and set a sniffer up! I completely forgot this was a thing.

Karl Ylvisaker said:

Great - this is the first step in resolving the issue. Could you confirm for me that you've added the DEBUG define in the common build configuration, as mentioned earlier? I notice that your logger is not outputting a complete error message.

Oh you were spot on - I added it to the release build config. This time I added it to the projects common build config and I'm getting a proper error out now.

<error> app: ERROR 19 [NRF_ERROR_RESOURCES] at C:\Users\...\main.c:235
PC at: 0x0002B1F5
<error> app: End of error report

Now after some googling I found this thread where someone seems to have the same problem and the issue is - you guessed it "Too many notifications queued." For that user it seems to have boiled down to their notification queue being too small but while trying to learn how they've changed it I've come across a few new questions:

The linked thread implies that this queue size is part of the BLE stack. If that's the case the BLE 'stack' includes not just the BLE drivers but also the memory interface between the CPU & the drivers. Is that right?
In ble_stack_init() (in main.c), there is nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start); The linked thread implies this sets a default queue size to BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT (which is 1). Firstly, is there a max queue size? Ideally i'd just set it to the max using sd_ble_cfg_set() - BUT I can't find a single reference to sd_ble_cfg_set() in the existing solution. Do you have any pointers to where I may be able to find an example so I can safely call sd_ble_cfg_set() with a new queue size?
Now, assuming I get that set, in order to maximize my throughput, I can set my connection interval to as small as possible (7.5ms, right?), maximize my MTU (to 251, right?), set my PHY to 2M, and then set my total number of links to just 1 (so that I don't have to share bandwidth). Once I get a sniffer up and running, I'll hopefully be able to confirm that all of that is the case after trying to test it out.

As always, thank you for your patience and help! I realize a lot of these are basic questions - I can't describe how appreciative I am of your time/effort.

Kindest regards,

Ryan

RE: SPI & Bluetooth best practices

ryerye120 — Wed, 20 Oct 2021 20:48:26 GMT

Hi Karl,

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/335010#335010"]What are you currently using as your central?[/quote]

I'm using an nrf52 dongle that's acting like a BLE<->USB pipe. I built this based off of the ble_uart_c example and took stuff from the usbd_ble_uart peripheral when needed.

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/335010#335010"]The best tool for debugging connectivity and throughput issues is the nRF Sniffer tool which lets you monitor on-air BLE traffic. Are you familiar with this tool already?[/quote]

I've heard of it but haven't used it - I'll order another dev kit and set a sniffer up! I completely forgot this was a thing.

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/335010#335010"]Great - this is the first step in resolving the issue. Could you confirm for me that you've added the DEBUG define in the common build configuration, as mentioned earlier? I notice that your logger is not outputting a complete error message.[/quote]

Oh you were spot on - I added it to the release build config. This time I added it to the projects common build config and I'm getting a proper error out now.

<error> app: ERROR 19 [NRF_ERROR_RESOURCES] at C:\Users\...\main.c:235
PC at: 0x0002B1F5
<error> app: End of error report

The linked thread implies that this queue size is part of the BLE stack. If that's the case the BLE 'stack' includes not just the BLE drivers but also the memory interface between the CPU & the drivers. Is that right?
In ble_stack_init() (in main.c), there is nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start); The linked thread implies this sets a default queue size to BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT (which is 1). Firstly, is there a max queue size? Ideally i'd just set it to the max using sd_ble_cfg_set() - BUT I can't find a single reference to sd_ble_cfg_set() in the existing solution. Do you have any pointers to where I may be able to find an example so I can safely call sd_ble_cfg_set() with a new queue size?
Now, assuming I get that set, in order to maximize my throughput, I can set my connection interval to as small as possible (7.5ms, right?), maximize my MTU (to 251, right?), set my PHY to 2M, and then set my total number of links to just 1 (so that I don't have to share bandwidth). Once I get a sniffer up and running, I'll hopefully be able to confirm that all of that is the case after trying to test it out.

As always, thank you for your patience and help! I realize a lot of these are basic questions - I can't describe how appreciative I am of your time/effort.

Kindest regards,

Ryan

RE: SPI & Bluetooth best practices

Karl Ylvisaker — Wed, 20 Oct 2021 08:37:07 GMT

[quote user="ryerye120"]From my understanding/corroborated by the link, I need to make sure my central device sets the PHY to 2Mbps. It should be that way already - is there a way to ask the peripheral to print what the PHY setting is via a debug statement?[/quote]

Yes, using the 2M PHY is important to achieve a high throughput.
If you scan and advertise on the 2M PHY the connection will also use 2M PHY. If you wish you could print something in the PHY UPDATED event, in the case that this should change at any time. What are you currently using as your central?
The best tool for debugging connectivity and throughput issues is the nRF Sniffer tool which lets you monitor on-air BLE traffic. Are you familiar with this tool already?
In case you are not you can find its documentation here. It is a powerful tool to wield when developing with BLE.

[quote user="ryerye120"]As you expected, the device starts to hang and I get thrown into an error. Unfortunately, I'm having a really hard time finding a stack trace that gives me more info. This is what I see in segger:[/quote]

Great - this is the first step in resolving the issue. Could you confirm for me that you've added the DEBUG define in the common build configuration, as mentioned earlier? I notice that your logger is not outputting a complete error message.

[quote user="ryerye120"]That's encouraging to hear. When I add the SPI driver into this project, I'll shift everything just to the spi trx' interrupt handler![/quote]

Great, I'm happy to hear that you found the comment encouraging! 🙂

Best regards,
Karl

RE: SPI & Bluetooth best practices

ryerye120 — Tue, 19 Oct 2021 21:11:55 GMT

Hi Karl,

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/334791#334791"] The queue is FIFO, and the notification will be sent as soon as there is room for it in an upcoming connection event.[/quote]

Ahhh this makes a lot of sense. This seems like a likely issue because BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT isn't defined in my sdk_config.h either. I'm assuming this is a peripheral device thing since it has to do with notifications (which is what I'm working on right now).

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/334791#334791"]You could take a look at the SoftDevice's throughput documentation for this - it details the parameters used to achieve the highest connection throughput. Have you calculated what throughput you will need for your application? Is there a constraint on the latency of the transfers?[/quote]

Yes! Ultimately I'll need to hit about 1Mbps so my goal is to transfer about 500 bits every 500 microsec (which means I should be transferring about 1000 bits total in every millisecond -> 1000kbps). From my understanding/corroborated by the link, I need to make sure my central device sets the PHY to 2Mbps. It should be that way already - is there a way to ask the peripheral to print what the PHY setting is via a debug statement?

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/334807#334807"]I just noticed that you do not immediately check the error code returned from ble_nus_data_send. I strongly recommend that you always pass the returned error code directly to an APP_ERROR_CHECK in order to be alerted to any possible failings by the function. [/quote]

Ah great point! I've added an app error check and the pertinent code is now:

  if ((ble_ready == NRF_SUCCESS)) { // & (app_fifo_get(&EE_rx_fifo, EE_transfer_buffer) == NRF_SUCCESS)){
    // uint16_t size2 = sprintf(m_tx_buffer, "%d \r\n", *EE_transfer_buffer);
    uint16_t size2 = sprintf(m_tx_buffer, "%d \r\n", test_counter);
    ble_ready = ble_nus_data_send(&m_nus, (uint8_t *) m_tx_buffer, &size2, m_conn_handle);
    APP_ERROR_CHECK(ble_ready);
  }

As you expected, the device starts to hang and I get thrown into an error. Unfortunately, I'm having a really hard time finding a stack trace that gives me more info. This is what I see in segger:

I figure the real error I need to fix is 0x00730075 but I can't figure out what this error is. So far I've looked through sdk_errors.h, nrf_error.h, and google and haven't been able to understand. Clearly, I don't understand the error hierarchy - is there a more detailed guide somewhere describing these? I've been trying to go through the appropriate nrf52 s140 documentation infocenter but if anything I'm more confused.

As a side note:

[quote userid="87869" url="~/f/nordic-q-a/80640/spi-bluetooth-best-practices/334791#334791"]The ble_nus_data_send call could also happen as part of the SPI event handler, so that you do not have to wait in the timer interrupt for the SPI transaction to complete before you can queue the data for transfer, for instance.[/quote]

That's encouraging to hear. When I add the SPI driver into this project, I'll shift everything just to the spi trx' interrupt handler!

RE: SPI & Bluetooth best practices

Karl Ylvisaker — Tue, 19 Oct 2021 09:35:15 GMT

Hello again, Ryan

I just noticed that you do not immediately check the error code returned from ble_nus_data_send. I strongly recommend that you always pass the returned error code directly to an APP_ERROR_CHECK in order to be alerted to any possible failings by the function. There might be an unexpected condition or situation that makes a function call fail, and checking the returned error code is the only way you may know that this has happened.

This is likely also the reason why you might be seeing 'lost data' - if the call to queue data for sending fails, and your application proceeds as if it succeeded, it will discard the data and move on to the next.
The returned error codes will also let you know exactly how to remedy the issue (by looking up the returned error code in the function's API reference) if you have DEBUG defined in your preprocessor defines, like shown in the included image:

This will make a detailed error message be outputted by your logger whenever a non-NRF_SUCCESS error code is passed to an APP_ERROR_CHECK.

Best regards,
Karl

RE: SPI & Bluetooth best practices

Karl Ylvisaker — Tue, 19 Oct 2021 09:04:09 GMT

Hello again,

[quote user="ryerye120"]As always, Karl, thank you so much for your help.[/quote]

It is no problem at all, Ryan, I am happy to help!

[quote user="ryerye120"]I'm under the assumption the timer will always leave enough time for the ble_nus_data_send to do its thing.[/quote]

The ble_nus_data_send function does not actually send the data directly, but it queues the notification for sending (placing it in the hvn queue). The queue is FIFO, and the notification will be sent as soon as there is room for it in an upcoming connection event.
- This is why it is important that your queue size is at minimum large enough to hold all notifications you intend to generate over the span of your connection interval. I say at minimum because you also need to account for possible retransmission due to corrupted packets or otherwise lost packets (data is never lost in the link since the un-acknowledged packet will be retransmitted).

[quote user="ryerye120"]I've set up the Bluetooth transfer inside the timer's interrupt handler.[/quote]

The ble_nus_data_send call could also happen as part of the SPI event handler, so that you do not have to wait in the timer interrupt for the SPI transaction to complete before you can queue the data for transfer, for instance.

[quote user="ryerye120"]The only ones I changed were the min and max_conn_interval:[/quote]

This is indeed how you change the connection interval preferences of the peripheral - but keep in mind that it is always the central that actually determines what connection parameters will be used. The peripheral may only send connection parameter update requests in order to ask the central to change to parameters within its preferences, but the central is free to reject these requests.
If the central rejects the peripheral can either accept the parameters used by the central, or terminate the link. Many applications such as nRF Connect for smartphone etc. will accommodate any preferences, but some native applications might not in order to save power on the central device. Certain phone OS's especially limit this, in order to avoid excess power consumption.

[quote user="ryerye120"]I can't find any BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT in the project or ble_gatt.h.[/quote]

Does it not exist in your sdk_config.h file? The sdk_config is used to set all these types of defines and configurations for your project in the nRF5 SDK.

[quote user="ryerye120"]Are there any other connection parameters you think I should update to speed up the bluetooth speed?[/quote]

You could take a look at the SoftDevice's throughput documentation for this - it details the parameters used to achieve the highest connection throughput. Have you calculated what throughput you will need for your application? Is there a constraint on the latency of the transfers?

Best regards,
Karl

RE: SPI & Bluetooth best practices

ryerye120 — Tue, 19 Oct 2021 06:16:06 GMT

Karl!

Hi Karl,

I've been able to get something to work but it still can't run at max speed. Per your suggestion, I've set up the Bluetooth transfer inside the timer's interrupt handler. I fixed one problem - I had a 'while (ble_ready == success)' gating the ble_nus_data_send - removing that helped things a little. I figure this is okay because I'm under the assumption the timer will always leave enough time for the ble_nus_data_send to do its thing. My timer's interrupt handler is below:

static void trx_timer_handler(void * p_context)
{
  // fire off a SPI transaction

  // For now, just send an incrementing counter over BLE
  if (test_counter == 15) {
    test_counter = 0;
  } else {
    test_counter = test_counter + 1;
  }
  

  //app_fifo_put(&EE_rx_fifo, test_counter);

  if ((ble_ready == NRF_SUCCESS)) { // & (app_fifo_get(&EE_rx_fifo, EE_transfer_buffer) == NRF_SUCCESS)){
    // uint16_t size2 = sprintf(m_tx_buffer, "%d \r\n", *EE_transfer_buffer);
    uint16_t size2 = sprintf(m_tx_buffer, "%d \r\n", test_counter);
    ble_ready = ble_nus_data_send(&m_nus, (uint8_t *) m_tx_buffer, &size2, m_conn_handle);
  }
}

This works if I slow the timer down - if it triggers once every 3ms I don't drop any packets. Unfortunately, when I speed the timer up to trigger every 500us (which is my target), I start "dropping" packets. I suspect this is because I'm effectively trying to queue notifications faster than I can send them.

I'm using most of the default connection parameters from the ble_app_uart example! The only ones I changed were the min and max_conn_interval:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)             /**< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)             /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */

Are there any other connection parameters you think I should update to speed up the bluetooth speed? I can't find any BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT in the project or ble_gatt.h. Is this something I need to implement? Is there an example that implements this? I'm currently using NRF5 sdk 17 with the nrf52840 DK.

As always, Karl, thank you so much for your help.

RE: SPI & Bluetooth best practices

Karl Ylvisaker — Mon, 18 Oct 2021 08:12:27 GMT

Hello,

[quote user="ryerye120"]This was incredibly helpful![/quote][quote user="ryerye120"]Thanks again for all of your help![/quote]

No problem at all, Ryan - I am happy to hear that you found my comment helpful!

[quote user="ryerye120"]To make things simpler for now, I am leaving the SPI out and just using my 500us timer to increment a counter. I then have an if statement in my main while loop that sends the updated counter to another device over bluetooth. Is this the best way to organize fast transactions through bluetooth?[/quote]

In general, the best way to do this is to handle it as part of an event handler, rather than having it happen in the main loop. This way you can easily control its priority, and compartmentalize the code better (not have everything running in the main loop).
Additionally, for power saving, you should only have the SYSTEM_ON sleep (idle_state_handler function in the BLE Peripheral examples) happen in the main loop, since this will make your system go to SYSTEM_ON sleep whenever there are no other work to be done.
I would therefore recommend that you either have the transfers happens as the handler to a TIMER CC event, or similar.

[quote user="ryerye120"]I must be doing something wrong because I'm losing a lot of data (I suspect the bluetooth transactions are taking too long - or the cpu is getting halted for too long so the counter increments more than once between bluetooth transfers. I tried putting the ble_nus_data_send() command in my timer's interrupt handler but that just caused nrf52840 to hang and become unresponsive.[/quote]

Could you possibly show some code of how you are doing this? Are you getting any error codes returned from your call to queue the data for sending? You could see the likely returned error codes in the sd_ble_gatts_hvx API reference documentation.
Since data is never lost in the link it is likely that you are dropping the data in the case that it fails to queue - for example if the HVN queue is already full. This could happen if you are queueing notifications faster than you are sending them, or if your hvn queue is not big enough to accommodate all the notifications generated between each connection event.
What connection parameters are you using for your application, and how big is your BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT?

Best regards,
Karl

RE: SPI & Bluetooth best practices

ryerye120 — Fri, 15 Oct 2021 19:23:10 GMT

Hi Karl,

This was incredibly helpful! I'll play with the SPIM peripheral/drivers and take a look at the SAADC example!

I have one more question regarding best practices - this time with my 'main mode of operation'. Eventually, I will have a timer triggering a SPI transaction every 500us. The resulting data from this SPI transaction will then be beamed via bluetooth.

To make things simpler for now, I am leaving the SPI out and just using my 500us timer to increment a counter. I then have an if statement in my main while loop that sends the updated counter to another device over bluetooth. Is this the best way to organize fast transactions through bluetooth? I must be doing something wrong because I'm losing a lot of data (I suspect the bluetooth transactions are taking too long - or the cpu is getting halted for too long so the counter increments more than once between bluetooth transfers. I tried putting the ble_nus_data_send() command in my timer's interrupt handler but that just caused nrf52840 to hang and become unresponsive.

I'm currently building off of the ble_app_uart examples.

Thanks again for all of your help!

Ryan

RE: SPI & Bluetooth best practices

Karl Ylvisaker — Fri, 15 Oct 2021 10:56:14 GMT

Hello Ryan,

Thank you for your patience with this.

[quote user=""]If this was one way then it would be especially straight forward but unfortunately, the NRF52840 can also receive commands from the dongle (over bluetooth) that may or may not trigger specific SPI transactions. It seems to me that the best way to organize the NRF52840 (that's talking to the custom IC) as the peripheral and the dongle as the central device. This way the peripheral can use an interrupt to query the IC and then notify the central device with a new packet.[/quote]

Fortunately, it does not have to be complicated just because it is two way! :)

[quote user=""]I'm having a little more trouble with the other main function though (dongle sending commands to the peripheral) though since it's really important that this bluetooth connection runs as fast as possible without dropping any packets.[/quote]

The BLE protocol is lossless, so you can be certain that no packets will be lost in the link. The only way packets may be lost is if they are not handled correctly when queued to be transferred by the SoftDevice on one side (such as if the queue command returns an error, and the program proceeds as though nothing had happened - dropping the packet that failed to be queued), or if the packet is discarded after reception on the central side.
You will also not have to worry about bogging down the speed of your BLE transfers with your application, since the SoftDevice takes priority over any application-layer task. This way, the SoftDevice will always be guaranteed to meet its BLE timing-critical deadlines, since it knows that it can control the CPU whenever it needs to.
So you may configure your connection parameters to whatever you would like, and the SoftDevice will make sure it is met - it is rather the application that must adjust to the possibility that the SoftDevice will take control of the CPU at any time in the program.

[quote user=""]Is it fair to have a main while loop on all my devices that spins (just checking if there's been an incoming command) when they're in their main interrupt-driven operating mode.[/quote]

Are you here referring to an incoming BLE event, or SPI transaction containing some command? I assume the former, and in this case you will not need to have a spinning while loop that checks for received commands, since the SoftDevice will take control of the CPU (even wake it if in SYSTEM_ON sleep) to meet the connection event and receive the command.

[quote user=""]Then if there has been a command, they break out of their interrupt-driven mode and work on whatever the command is?[/quote]

This also happens as part of the ble_evt_handler or specific service event handler you've implemented. When the SoftDevice has completed a connection event it will forward the data received (like a write to a command characteristic) to the the appropriate event handler in the application layer. Provided that the particular event handler has a high enough priority it can then be executed right away.
You can see how this in done in most of the BLE peripheral examples. To be specific, you could take a look at the BLE UART peripheral example where the NUS events are forwarded to the nus event handler and processed immediately upon the application resuming control over the CPU.

[quote user=""]I worry that this constant spinning may burn unnecessary power and also may slow down the main BLE operation (which needs to run as fast as possible!).[/quote]

As mentioned the BLE operation will happen at the configured rate regardless of what the application is doing. The CPU might very well be in the low power SYSTEM_ON sleep state for most of the time, ready to receive BLE commands in the next connection event. All of our BLE peripheral examples demonstrate this - the idle_state_handler which is running in the main while loop places the CPU in SYSTEM_ON sleep whenever there is nothing else that needs doing. The CPU will then be ready to quickly wake up as soon as there is an event generated.

[quote user=""]Are there other alternatives that may allow the bluetooth and spi to operate as fast as possible in parallel?[/quote]

Yes, this is a good question - how to proceed in order to operate the SPI when the CPU might be claimed by the SoftDevice at any time.
The answer to this is to make use of the nRF52840's easyDMA feature through using the SPIM peripheral (rather than the SPI), since this utilizes easyDMA.
easyDMA lets a peripheral access RAM without needing CPU intervention. You could therefore both receive or send (if queued in advanced) data while the CPU is busy with the SoftDevice. To achieve this totally without CPU intervention you would need to also make use of the PPI peripheral, which lets you connect an event to a task trigger - i.e that when a specific event occurs, you would have it trigger a task (such as TASKS_START) without needing to involve the CPU.
You could see the PPI peripheral demonstrated in the SAADC peripheral example where it is used to connect a TIMER CC event to the SAADC's TASKS_SAMPLE - enabling the SAADC to sample periodically without concern that the CPU might not be available at the particular time the sampling should happen.

Please do not hesitate to ask if any part of this should be unclear, or if you encounter any other issues or questions!

Best regards,
Karl