[SPIM + NUS] conflict between the SPIM and BLE thread.

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Tue, 10 Sep 2024 13:21:22 GMT

I just realized that some data might have been lost during the NUS or UART process... I'm really sorry. I'll review both NUS and UART.

+ I have discovered an issue where the initial packets are missing on the central side.
Thank you so much for your help so far.
I will address the data loss issue with NUS and UART in a separate ticket. Your advice has been helpful to me

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Tue, 10 Sep 2024 09:45:52 GMT

[quote userid="2121" url="~/f/nordic-q-a/114453/spim-nus-conflict-between-the-spim-and-ble-thread/501736"]Please show your test result with some dummy data so I can get to understand what your problem is. Please provide the log.[/quote]

okay.I'll get back to you as soon as possible.

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Tue, 10 Sep 2024 08:18:11 GMT

First of all, thank you so much for your response.

< Test Results for SPIM and NUS >
1. SPIM (Executed Individually)
- SPIM communication occurs consistently according to the 'TIME_TO_WAIT_US' variable.
- It was confirmed that SPIM works correctly when TIME_TO_WAIT_US is above a certain threshold.
- 'result for spim_tx_buf_repeat' was printed successfully. 'result for spim_tx_buf_initial' was printed successfully.

2. NUS (Executed Individually)
- NUS functions well when executed individually.

3. SPIM + NUS Simultaneous Execution
- When SPIM and NUS are executed simultaneously, the issue previously mentioned occurs again.

[quote userid="132399" url="~/f/nordic-q-a/114453/spim-nus-conflict-between-the-spim-and-ble-thread/501625"]There are a few issues. The SPIM result for the spim_tx_buf_initial command is missing, and only the result for spim_tx_buf_repeat is printed to NUS. To address this, I added a few variables for debugging as shown below.(The commented-out section is the part that has been modified.)[/quote]

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

Hung Bui — Mon, 09 Sep 2024 12:35:35 GMT

Hi Seongmin,

It's getting quite hard to follow here.
My suggestion is to try to isolate the problem and simplify the application so you can spot where the issue is.
As I mentioned, please try to simply printout on the log the fifo buffer instead of sending it over BLE. This way we can take BLE out of the picture and focus the debugging on SPI and the FIFO buffer.

Please show your test result with some dummy data so I can get to understand what your problem is. Please provide the log.

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Mon, 09 Sep 2024 01:10:56 GMT

Hello. I followed your advice and coded accordingly. Below are the modified sections, while the rest remains the same as in the previous code

static struct fifo_data_t {
   void *fifo_reserved; // This must be the first element for FIFO
   uint8_t data[122][2]; // Buffer to hold the data
   uint16_t len; // Length of the data 
};

K_FIFO_DEFINE(nus_fifo);

struct fifo_data_t *spim_buf = NULL; 
static volatile uint16_t buffer_index = 0;

//////////////////////////////////////////////////

void spim1_handler(nrfx_spim_evt_t const * p_event, void * p_context) { 

   if (spim_buf == NULL) {
      spim_buf = k_malloc(sizeof(struct fifo_data_t));
      if (spim_buf == NULL) {
         LOG_ERR("Failed to allocate memory for FIFO buffer:%d", buffer_index);
         return;
      }
      spim_buf->len = 0;  
   }

   memcpy(spim_buf->data[buffer_index], spim_rx_buf_A[buffer_index], 2);   
   buffer_index++;
   spim_buf->len++;

   if (!initialization_stop) {
      initialization_counter++;

      if (initialization_counter == 30) {
         initialization_stop = true;
         spim1_inst.p_reg->TXD.PTR = (uint32_t)spim_tx_buf_repeat[0];
      }

      return;
   }

   if (buffer_index >= 120){    //if (buffer_index >= 100 && repeat_counter % 18 == 0){
      k_fifo_put(&nus_fifo, spim_buf); 
      
      spim1_inst.p_reg->RXD.PTR = (uint32_t)spim_rx_buf_A[0];
      buffer_index = 0;

      spim_buf = NULL;
   }

   repeat_counter++;
   if (repeat_counter % 18 == 0) {
      spim1_inst.p_reg->TXD.PTR = (uint32_t)spim_tx_buf_repeat[0];
      repeat_counter = 0;
   }
}

void ble_write_thread(void){
   int ret;
   struct fifo_data_t *nus_buf;

   k_sem_take(&nus_start, K_FOREVER);
   LOG_WRN("Starting BLE Write Thread");
   while (1) {
      nus_buf = k_fifo_get(&nus_fifo, K_FOREVER);
      ret = bt_nus_send(current_conn, (uint8_t *)nus_buf->data, 2*(nus_buf->len));

      k_free(nus_buf);

      if (k_sem_take(&disconnect_sem, K_NO_WAIT) == 0){
         LOG_WRN("Disconnected, exiting BLE Write Thread");
         return;
      }
   }
}

K_THREAD_DEFINE(ble_write_thread_id, 8192, ble_write_thread, NULL, NULL, NULL, PRIORITY, 0, 0);

There are a few issues. The SPIM result for the spim_tx_buf_initial command is missing, and only the result for spim_tx_buf_repeat is printed to NUS. To address this, I added a few variables for debugging as shown below.(The commented-out section is the part that has been modified.)

// #define MAX_SPI_COUNT 400
// static K_SEM_DEFINE(debugging, 0, 1);
// uint32_t recording[MAX_SPI_COUNT];
// int spim_count = 0;
///////////////////////////////////////////////////

// void spi_disable(NRF_SPIM_Type *p_spim_instance){
//     nrfy_spim_disable(p_spim_instance);
//     nrf_spim_int_disable(p_spim_instance, 0xFFFFFFFF);
// }

// void timer_disable(nrfx_timer_t *p_timer_instance){
//     nrfx_timer_disable(p_timer_instance);
//     nrfx_timer_uninit(p_timer_instance);
// }  

void spim1_handler(nrfx_spim_evt_t const * p_event, void * p_context) { 
   //LOG_INF("spim1_handler- buffer_index: %d, spim_buf->len: %d ",buffer_index, spim_buf->len);
   //LOG_INF("spim1_handler- initialization_counter: %d",initialization_counter);
   //LOG_INF("spim1_handler- 0x%02x%02x",spim_rx_buf_A[buffer_index][0], spim_rx_buf_A[buffer_index][1]);
   // LOG_INF("spim1_handler- %d >> RXD.PTR: 0x%08x", buffer_index, (uint32_t)spim1_inst.p_reg->RXD.PTR);
   // LOG_INF("spim1_handler- %d >> TXD.PTR: 0x%08x", buffer_index, (uint32_t)spim1_inst.p_reg->TXD.PTR);
   // if(spim_count >= MAX_SPI_COUNT){                
   //    timer_disable(&timer1_inst);
   //    spi_disable(spim1_inst.p_reg);
   //    k_sem_give(&debugging);
   //    LOG_INF("<<<< SPIM+TIMER END  >>>>");
   //    return;
   // } 
   //recording[spim_count] = (uint32_t)spim1_inst.p_reg->RXD.PTR;
   //recording[spim_count] = (uint32_t)initialization_counter;
   //recording[spim_count] = (uint32_t)initialization_stop;
   //recording[spim_count] = (uint32_t)repeat_counter;
   // spim_count++;

   if (spim_buf == NULL) {
      spim_buf = k_malloc(sizeof(struct fifo_data_t));
      if (spim_buf == NULL) {
         LOG_ERR("Failed to allocate memory for FIFO buffer:%d", buffer_index);
         return;
      }
      spim_buf->len = 0;  // Initialize the length of the data
   }

   memcpy(spim_buf->data[buffer_index], spim_rx_buf_A[buffer_index], 2);    //void *memcpy(void *dest, const void *src, size_t n); 
   //recording[spim_count] = (uint32_t)buffer_index;

   buffer_index++;
   spim_buf->len++;

   if (!initialization_stop) {
      initialization_counter++;

      if (initialization_counter == 30) {
         initialization_stop = true;
         spim1_inst.p_reg->TXD.PTR = (uint32_t)spim_tx_buf_repeat[0];
      }

      return;
   }

   if (buffer_index >= 120){    //if (buffer_index >= 100 && repeat_counter % 18 == 0){

      k_fifo_put(&nus_fifo, spim_buf); 
      
      spim1_inst.p_reg->RXD.PTR = (uint32_t)spim_rx_buf_A[0];
      buffer_index = 0;

      spim_buf = NULL;
   }

   repeat_counter++;
   if (repeat_counter % 18 == 0) {
      spim1_inst.p_reg->TXD.PTR = (uint32_t)spim_tx_buf_repeat[0];
      repeat_counter = 0;
   }
}

int main(void){
   nrfx_err_t status;
   (void)status;
   int err;

   LOG_INF(" -----------      revision      ----------- ");

   /************ BLE ***********/ 
   bt_conn_cb_register(&conn_callbacks); 
   err = bt_conn_auth_info_cb_register(&conn_auth_info_callbacks); 
   //LOG_INF("main - bt_conn_auth_info_cb_register: %d",err);
   err = bt_enable(NULL);
   //LOG_INF("main - bt_enable: %d",err);
   if (IS_ENABLED(CONFIG_SETTINGS)) {
      settings_load();
   }
   err = bt_nus_init(&nus_cb);
   //LOG_INF("main - bt_nus_init(&nus_cb): %d",err);
   err = bt_le_adv_start(BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));
   //LOG_INF("main - bt_le_adv_start: %d",err);   
   k_sem_take(&ble_setup_sem1, K_FOREVER);
   k_sem_take(&ble_setup_sem2, K_FOREVER);
   k_sem_take(&ble_setup_sem3, K_FOREVER);

   /************ SPIM ************/ 
   initialization_command();
   #if defined(__ZEPHYR__)
      IRQ_CONNECT(NRFX_IRQ_NUMBER_GET(NRF_SPIM_INST_GET(SPIM_INST_IDX)), IRQ_PRIO_LOWEST,     
                              NRFX_SPIM_INST_HANDLER_GET(SPIM_INST_IDX), 0, 0);
      IRQ_CONNECT(NRFX_IRQ_NUMBER_GET(NRF_TIMER_INST_GET(TIMER_INST_IDX)), IRQ_PRIO_LOWEST, 
                              NRFX_TIMER_INST_HANDLER_GET(TIMER_INST_IDX), 0, 0);
   #endif
   LOG_INF("main - TIME_TO_WAIT_US: %d [us],  total_sampling_rate: %ld [Hz],  per_ch_SAMPLE_RATE: %ld [Hz]", TIME_TO_WAIT_US, total_sampling_rate, per_ch_SAMPLE_RATE);
   status = nrfx_gpiote_init(&gpiote_inst, NRFX_GPIOTE_DEFAULT_CONFIG_IRQ_PRIORITY);
   //LOG_INF("main - nrfx_gpiote_init: %d", status);
   status = nrfx_gpiote_channel_alloc(&gpiote_inst, &out_channel);
   //LOG_INF("main - nrfx_gpiote_channel_alloc: %d", status);
   LOG_INF("---------------------------------------------------------------------");
   LOG_INF("main - spim_tx_buf_initial address[0]: %p", (void*)&spim_tx_buf_initial[0][0]);
   LOG_INF("main - spim_tx_buf_initial address[29]: %p", (void*)&spim_tx_buf_initial[29][0]);
   LOG_INF("main - spim_tx_buf_repeat address[0]: %p", (void*)&spim_tx_buf_repeat[0][0]);
   LOG_INF("main - spim_tx_buf_repeat address[17]: %p", (void*)&spim_tx_buf_repeat[17][0]);
   LOG_INF("main - spim_rx_buf_A address[0]: %p", (void*)&spim_rx_buf_A[0][0]);
   LOG_INF("main - spim_rx_buf_A address[243]: %p", (void*)&spim_rx_buf_A[243][0]);

   LOG_INF("---------------------------------------------------------------------");
/*    for(int y=0 ; y < 30; y++){
      LOG_INF("main - spim_tx_buf_initial address: %p", (void*)&spim_tx_buf_initial[y][0]);
   }
      LOG_INF("---------------------------------------------------------------------");
   for(int y=0 ; y < 18; y++){
      LOG_INF("main - spim_tx_buf_repeat address: %p", (void*)&spim_tx_buf_repeat[y][0]);
   }
   LOG_INF("---------------------------------------------------------------------"); */
   peripheral_setup();
   nrfx_gpiote_out_task_enable(&gpiote_inst, SS_PIN_MASTER);
   nrfx_gppi_channels_enable(BIT(ppi_channel_spi_start));
   nrfx_gppi_channels_enable(BIT(ppi_channel_spi_end));
   nrfx_timer_enable(&timer1_inst);
   k_sem_give(&nus_start);
   //k_sem_take(&debugging, K_FOREVER);
   //for(int i=0; i<400; i++){
      //LOG_INF("spim1_handler- %d >> RXD.PTR: 0x%08x", i, recording[i]);
      //LOG_INF("spim1_handler- %d >> buffer_index: %d", i, recording[i]);
      //LOG_INF("spim1_handler- %d >> initialization_counter: %d", i, recording[i]);
      //LOG_INF("spim1_handler- %d >> repeat_counter: %d", i, recording[i]);
   //}

   return 0;
}

However, after adding these variables, the SPIM result for the spim_tx_buf_initial command is no longer missing. What could be the issue?

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Fri, 06 Sep 2024 09:59:47 GMT

Okay, I'll try that. I'll get back to you as soon as possible.

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

Hung Bui — Fri, 06 Sep 2024 08:12:27 GMT

Hi Seongmin,
Yes correct. The main point is that the BLE stack doesn't buffer the data until it's sent. So you need to make sure the data buffer is not modified until the BLE function is returned.

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Fri, 06 Sep 2024 07:44:08 GMT

Is the key point of your advice using 'FIFO' and creating a 'temporary buffer to store data'?

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

Hung Bui — Thu, 05 Sep 2024 13:13:44 GMT

Hi Seongmin,

I think you may want to look at how we handle UART buffer in NUS sample of using k_fifo. Notice how the buffer is initialized at each UART_RX_BUF_REQUEST event. And then free after it's sent by bt_nus_send()

As I mentioned if you simply share the same buffer between BLE and SPI you will run into the issue that SPI may change the data before it's sent via BLE.

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Thu, 05 Sep 2024 11:50:36 GMT

First of all, thank you so much for your response.

When using SPIM alone, there were no issues, and all debugging has been completed. Additionally, even when NUS and SPIM used separate buffers, the tests were conducted and everything worked fine in that case as well. (Additionally, I measured SS, SCK, MOSI, and MISO with an oscilloscope to confirm this.)

The problem arises when the buffer is shared between the SPIM handler and the NUS thread. SPIM itself operates correctly, as confirmed by the oscilloscope, but sharing the buffer became unavoidable when I tried to send the data received by SPIM to NUS.

To address this, I implemented double buffering. However, I'm facing difficulties in writing the code due to the limitation that I cannot wait for or block the handler(in zephyr OS).

[quote userid="2121" url="~/f/nordic-q-a/114453/spim-nus-conflict-between-the-spim-and-ble-thread/501306"]Please try to do a memcpy to copy the SPI buffer to another buffer before sending as the BLE stack will not buffer it until it's sending. So if the content of the buffer is changed/updated before the BLE packet is sent you will send the wrong data.[/quote]

As you mentioned, are you referring to storing NUS_send_counter in temp like in my code(nus_thread)? I think it's a good idea. However, I'm concerned that memcpy might result in high CPU load.

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

Hung Bui — Thu, 05 Sep 2024 08:59:49 GMT

Hi Seongmin,
We currently don't have NUS and SPIM sample.

My suggestion is to try instead of sending over BLE, you can print out on the log the data should be sent by BLE. This way you can monitor if there is any problem with the SPI buffer.

Please correct me if I'm wrong, you are trying to test using a loopback ? The MOSI is connected to MISO, correct?

Please try to do a memcpy to copy the SPI buffer to another buffer before sending as the BLE stack will not buffer it until it's sending. So if the content of the buffer is changed/updated before the BLE packet is sent you will send the wrong data.

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Thu, 05 Sep 2024 04:27:34 GMT

MOSI: command, MISO: result

First of all, the data received from the sensor is the result (MISO) of the SPIM.

While debugging the data received via BLE, there is an issue where the pattern of data received from the sensor is not being output as expected.

After the result of the initial transmission (spim_tx_buf_initial) is successfully sent via BLE, only the result of the repeated transmission (spim_tx_buf_repeat) should be transmitted. However, even after the initial transmission is complete, some of the 'result of spim_tx_buf_initial' continues to be output. As a result, only the 'result of spim_tx_buf_repeat' should be repeated, but this is not happening as expected.

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

Hung Bui — Wed, 04 Sep 2024 14:42:20 GMT

Please show the full code. I don't see how spim_buffer assigned.

I don't see where you assign the SPI buffer spim_rx_buf_A to.

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Wed, 04 Sep 2024 14:38:00 GMT

Aside from your response, I have an additional request. Could I see an example code that integrates NUS and SPIM, similar to mine?

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Wed, 04 Sep 2024 14:35:08 GMT

First of all, thank you so much for your response.

I’ll organize the debugging of my code and get back to you!

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

Hung Bui — Wed, 04 Sep 2024 14:32:02 GMT

Hi,

Please try to give as much information as possible.
What exactly happened when

[quote user="seongmincho"] However, it seems that the tasks are not running as expected. [/quote]

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

seongmincho — Wed, 04 Sep 2024 14:01:55 GMT

Assumption:
Task1: SPIM Communication
Task2: SPIM Handler
Task3: NUS_send (Executed in ‘ble_write_thread’)

I would like the tasks to proceed as shown in the image below.

The number of Task1 and Task2 executions before Task3 runs doesn't matter. However, it seems that the tasks are not running as expected. In particular, I suspect that the transition between buffers in the double-buffering process is not working smoothly. I have tried using semaphores, mutexes, and locks, but only encountered errors, which leads me to believe that I haven't used them correctly.

Here is the code I’m using:

      temp_buffer = spim_buffer;  
      spim_buffer = nus_buffer;
      nus_buffer = temp_buffer;

      spim1_inst.p_reg->RXD.PTR = (uint32_t)spim_buffer;

RE: [SPIM + NUS] conflict between the SPIM and BLE thread.

Hung Bui — Wed, 04 Sep 2024 11:36:26 GMT

Hi Seongmin,

Could you elaborate more on the issue you are facing ? Please describe the issue in more detail.