[SPIM+USBD] Data loss between SPIM and USBD

RE: [SPIM+USBD] Data loss between SPIM and USBD

Hung Bui — Fri, 27 Sep 2024 11:14:27 GMT

Hi Seongmin,
I'm sorry for the late response and that I haven't got time to dig deeper in your code.

I don't see any loop or anything that can make the spim1_handler() take long time. So I am not sure why you think that the handler's task is too heavy. What you think that may take time? Have you tried to measure the time it take ?

You didn't mention that you use BLE in this question, so I thought that you only use USBD to send data to PC, not BLE. But we also need to figure out why BLE causing the problem.
Have you tried to use a logic analyzer to check the SPI communication ?

I'm not sure I understand about your switching TXD/RXD.PTR logic, you may want to explain it to me.

RE: [SPIM+USBD] Data loss between SPIM and USBD

seongmincho — Tue, 24 Sep 2024 02:02:42 GMT

After modifying the SPIM handler, we observed the following results:

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));
      spim_buf->len = 0;  
   }

   spim_buf->data[buffer_index][0] = spim_rx_buf_A[buffer_index][0];
   spim_buf->data[buffer_index][1] = spim_rx_buf_A[buffer_index][1];
   debug_ptr[buffer_index] = spim1_inst.p_reg->TXD.PTR;
   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];
         spim1_inst.p_reg->RXD.PTR = (uint32_t)spim_rx_buf_A[0];
         k_fifo_put(&uart_fifo, spim_buf); 
         buffer_index = 0;
         spim_buf = NULL;
      }
      return;
   }

   if (buffer_index == 108){    
      spim1_inst.p_reg->RXD.PTR = (uint32_t)spim_rx_buf_A[0];
      spim1_inst.p_reg->TXD.PTR = (uint32_t)spim_tx_buf_repeat[0];
      k_fifo_put(&uart_fifo, spim_buf); 
      buffer_index = 0;
      spim_buf = NULL;
   }


}

1. Overall data issues have decreased.

2. Data problems still persist, showing the following characteristics:
- Occurring at intervals of multiples of 108
- The occurrence timing was similar to the period of the NUS-connection interval

3. Increasing the TIME_TO_WAIT_US value resolved these data issues.

4. Initialization results were output in parts where repetition results were expected. The specific address values are as follows:
spim_tx_buf_initial address[0]: 0x20002313
spim_tx_buf_initial address[29]: 0x2000234d
spim_tx_buf_repeat address[0]: 0x2000223b
spim_tx_buf_repeat address[107]: 0x20002311

5. When using code such as debug_ptr[buffer_index] = spim1_inst.p_reg->TXD.PTR; for debugging, spim1_inst.p_reg->TXD.PTR did not function correctly.

Considering these observations, I can draw the following inferences and conclusions:
1) It appears that the TXD or RXD.PTR switching part within the handler is not functioning properly.
2) These issues are likely occurring because the handler's task is too heavy.

Im currently seeking solutions, and advice is needed particularly on the following two approaches:
1) Methods to reduce the handler's load
2) Ways to optimize the TXD/RXD.PTR switching logic

RE: [SPIM+USBD] Data loss between SPIM and USBD

seongmincho — Sat, 21 Sep 2024 07:49:00 GMT

[quote userid="2121" url="~/f/nordic-q-a/114813/spim-usbd-data-loss-between-spim-and-usbd/503303"]So you send 2 bytes - 16 bit every 45us ? Or it's 240 bytes every 45us ? [/quote]

'2 bytes - 16 bit every 45us' is correct !

+) The TIMER generates an event at regular intervals (TIME_TO_WAIT_US = 45), and this event triggers the start of SPIM transmission via PPI. This setup allows automatic, timer-based periodic SPIM transmissions.
For more details, please refer to the main code.( 'peripheral_setup' and 'spim_handler' functions)

RE: [SPIM+USBD] Data loss between SPIM and USBD

Hung Bui — Fri, 20 Sep 2024 14:47:54 GMT

Hi,

[quote user="seongmincho"]SPIM communication occurs every 45μs, and during each SPIM communication, 16-bit data is exchanged through MISO and MOSI. After 120 SPIM communications, a total of 120 * 16 bits, or 240 bytes, of data is stored in 'spim_buf', and this data is inserted into 'uart_fifo' using 'k_fifo_put(&uart_fifo, spim_buf)'.
[/quote]

So you send 2 bytes - 16 bit every 45us ? Or it's 240 bytes every 45us ?

[quote user="seongmincho"]Data loss occurs 2-3 times consecutively out of 2000 results (16 * 2000 bits). As a result, it seemed difficult to store and output the data in the buffer. However, now that I think about it, there might be a way to predict when data loss is likely to happen and store the data only during those times. I'll try that[/quote]

You can think of just storing it in RAM and then put a debug point and check the RAM to see if there is any issue. This way you don't have to use other way of printing the buffer out like USBD or UART.

Please do try to get a logic analyzer, it will make your life easier :)

RE: [SPIM+USBD] Data loss between SPIM and USBD

seongmincho — Fri, 20 Sep 2024 11:28:04 GMT

[quote userid="2121" url="~/f/nordic-q-a/114813/spim-usbd-data-loss-between-spim-and-usbd/503230"]My understanding is that you want to transmit every 45uS ? How many bytes you are transmitting on each session ? [/quote]

1) SPIM
assumption: TIME_TO_WAIT_US = 45 (45us)
SPIM communication occurs every 45μs, and during each SPIM communication, 16-bit data is exchanged through MISO and MOSI. After 120 SPIM communications, a total of 120 * 16 bits, or 240 bytes, of data is stored in 'spim_buf', and this data is inserted into 'uart_fifo' using 'k_fifo_put(&uart_fifo, spim_buf)'.

2) USBD
The USBD waits until data is available in the 'uart_fifo', and once the data arrives, it is transmitted via UART. One 'uart_fifo data block consists of 120 * 16 bits, or 240 bytes. (This is actually designed for BLE transmission, and since the MTU size for BLE is 244 bytes, the transmission unit was set to 240 bytes.)

[quote userid="2121" url="~/f/nordic-q-a/114813/spim-usbd-data-loss-between-spim-and-usbd/503230"]Have you tried to test without USBD and check if the buffer you receive via SPI has the correct data ?
[/quote]

Data loss occurs 2-3 times consecutively out of 2000 results (16 * 2000 bits). As a result, it seemed difficult to store and output the data in the buffer. However, now that I think about it, there might be a way to predict when data loss is likely to happen and store the data only during those times. I'll try that

[quote userid="2121" url="~/f/nordic-q-a/114813/spim-usbd-data-loss-between-spim-and-usbd/503230"]You can use a logic analyzer to verify that SPI communication is fine or not. It can visualize the communication and show you the data being transmitted on the lines. For example[/quote]

wow it's cool!!! but we don't have a logic analyzer in our lab, so I'll need to either ask my lab colleagues or inquire with another lab.

RE: [SPIM+USBD] Data loss between SPIM and USBD

Hung Bui — Fri, 20 Sep 2024 09:26:50 GMT

Hi Seongmin,

I'm happy to help :)
You are correct about isolating. When you see something doesn't work as it should, and if it's possible to break it down to smaller part. Try to break it down to smaller part and check if each part would do as it should.
For example in your case, you have SPI communication and USBD communication. They may affect each other. But you also need to check and verify SPI works as it should and USBD work as it should.

You can use a logic analyzer to verify that SPI communication is fine or not. It can visualize the communication and show you the data being transmitted on the lines. For example:

My understanding is that you want to transmit every 45uS ? How many bytes you are transmitting on each session ?

Have you tried to test without USBD and check if the buffer you receive via SPI has the correct data ?

After you enable USBD, you can also check on the SPI lines with the logic analyzer to see if there is any interruption. You are calling the UART sending from a thread, but I am not sure the UART/USB driver doesn't use interrupt, I think it does.

RE: [SPIM+USBD] Data loss between SPIM and USBD

seongmincho — Thu, 19 Sep 2024 12:27:46 GMT

Nice to see you again! You are my teacher!

1. Your point is valid. Increasing 'TIME_TO_WAIT_US' from 45 to 100 allows it to function properly without data loss. However, I need to keep 'TIME_TO_WAIT_US' at 45. Is there any other solution?

2. I am not entirely sure about the specific meaning of 'isolate' and 'logic analyzer.'
By 'isolate,' do you mean flashing only the spim code to check its operation? Or is it about checking the operation of just spim when both spim and usbd code are flashed together? (I used an oscilloscope to check the SPI signals and do not have other measurement hardware available. 😅)

3. Isn't the interrupt handler always supposed to have a higher priority than task of thread?

RE: [SPIM+USBD] Data loss between SPIM and USBD

Hung Bui — Thu, 19 Sep 2024 12:13:02 GMT

Hi Seongmin,

As mentioned in the previous ticket, please try to isolate the problem.
Please double check if you give the SPI enough time for communication with the TIME_TO_WAIT_US time.

As far as I can see if the SPI is handled by PPI and interrupt handler, it should have higher priority than the USB thread. You need to isolate the issue, try to use a logic analyzer to check the communication on SPI to see if it's OK or not. Then check the fifo buffer to see if there is any problem.