CC2340R5: CC2340 did transparent data transmission test, and found that the module sent 1 packet of data, and the APP received 2 times

Hi,

Thank you for reaching out and providing the logs.

Have you considered whether the observed behavior could be caused by packet errors and re-transmissions? (Which are expected with wireless communication)

For information, in the provided logs, I see at least 41 malformed packets, not counting the potentially packets missed both by the phone and the module.

Best regards,

Hi, Thank you for your reply

if the data packet is retransmitted incorrectly, should the APP only receive one set of data, and duplicate data protocol stacks will not be reported to the APP application layer. I looked at the APP's LOG and at this time point, I also received two sets of the same data

Hi,

My question was rather to see if the difference in the number of packets sent received could be explained by packet errors and re-transmissions :)
Other element potentially explaining this, is the fact the write and notify packets don't appear to alternate in a fixed pattern

When it comes to duplicate packets in the app, have you mentioned occurrences of duplicate packets in the log provided? (only considering the packets properly formed and properly acked). For the moment, I haven't found such occurrence, but I may have missed something.

Best regards,

Hi,

I supplement the APP's log. Two sets of the same data were received at 08-28 19:07:34.346 and 08-28 19:07:34.371. Normally, the data content sent by the APP to the module is fixed, and the first 4 bytes of data sent by the module to the APP are accumulated (244 bytes per packet). Module timing 20ms and APP timing 20ms, the time may not be synchronized, this is only to test two-way data transfer rate

APP->CC2340

88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 88 85 55 25 8B B7 88 88 88 88 88 88 88 88 85 55 78 55 55 77 55 55 55 55 66 65 47 78 55 54 77 55 57 77 85 55 58 85 55 58 85 58 89 66 88 88 7B

CC2340->APP（The first 4 bytes are cumulative, and 244 bytes are added each time）

00 87 C1 CC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA

log-ttc-ble.rar

Hi,

Thank you for the additional information.

I do see a duplication of the payload starting with 00 87 C3 B4 00... in the log.

It is interesting to notice that, when comparing the two packets, even if the ATT payloads are identical, the LL headers and CRCs are different.
It means the packet duplication comes from the host layer or from the application layer (on the module side).

A second interesting piece of information to notice is the packet duplication for the payloads 00 87 D2  XX 00, 00 87 E6  XX 00, 00 87 FA  XX 00, 00 87 FA  XX 00, 00 88 0F XX 00. For all these packets only the 4th byte changes (which does not seem to be the most frequent in the rest of the packets). Any idea why we observe this? Could it help us identifying a path forward?

Best regards,

Hi,

My code is as follows, the first 4 bytes of data sent each time will change. So it is not caused by the application layer repeatedly sending the same data. Besides, you said 00 87 D2xx00,00 87 E6xx00, and I didn't see any repetition.

uint8_t data[244]={0};
send_num += 244;

data[0] = send_num>>24;
data[1] = send_num>>16;
data[2] = send_num>>8;
data[3] = send_num&0xff;

data[242] = 0x55;
data[243] = 0xaa;
ttcProfileCharNotify(connHandle,charHandle,data,sizeof(data));

		
		
bStatus_t ttcProfileCharNotify(uint16_t connHandle, uint16_t charHandle, void *pData, uint8_t len)
{
  bStatus_t ret = SUCCESS;
  uint16    allocateLen;

  if( len != 0 && pData != NULL && connHandle != LINKDB_CONNHANDLE_INVALID)
  {
    attHandleValueNoti_t noti;
    
    // If the attribute value is longer than (ATT_MTU - 3) octets, then
    // only the first (ATT_MTU - 3) octets of this attributes value can
    // be sent in a notification.
    noti.pValue = (uint8 *)GATT_bm_alloc( 0, ATT_HANDLE_VALUE_NOTI, len, &allocateLen );


    if ( noti.pValue != NULL )
    {
      noti.handle = charHandle;
      noti.len = allocateLen;
      memcpy(noti.pValue, (uint8*)pData, allocateLen);
      
      ret = GATT_Notification(connHandle, &noti, FALSE );
      
      if ( ret != SUCCESS )
      {
        GATT_bm_free( (gattMsg_t *)&noti, ATT_HANDLE_VALUE_NOTI );

        //ret = bleNoResources;
      }
      else
      {
        
      }
    }
    else
    {
      ret = bleNoResources; 
    }
  }
  else
  {
    ret = bleInvalidRange;
  }


  if(ret != SUCCESS)
  {
    log_error("ttcProfileCharNotify fail:%d",ret);
  }


  return ( ret );
}

Hi,

So far I haven't managed to identify the root cause of the issue you have reported.

I'll work today to setup an experiment in order to reproduce the issue so I can report it to the R&D team.

In case you have some suggestions on ways to reproduce the issue more reliably, please let me know as it will speed up my investigations.

Please expect some feedback by end of next week.

Best regards,

Thank you very much.

My test method is that the module is timed for 20ms and executes the following code.

uint8_t data[244]={0};
send_num += 244;

data[0] = send_num>>24;
data[1] = send_num>>16;
data[2] = send_num>>8;
data[3] = send_num&0xff;

data[242] = 0x55;
data[243] = 0xaa;
ttcProfileCharNotify(connHandle,charHandle,data,sizeof(data));

Determine whether the data is abnormal by checking whether the value of send_num is the same as the number of bytes displayed on the APP.

APP sends out 244 bytes of data at regular intervals of 20 ms.Attached is my test APP.

昇润透传软件-V1.5.5-20230824-debug.rar

Hi,

I have one more question - I have noticed the connection interval is 15 ms, while the data is enqueued every 20 ms. Is it in accordance with your expectations?

Best regards,

The normal slave updates to the interval of 20ms, but according to the log, the slave's request to update the connection parameters failed, so the 15ms updated before the mobile phone was used. I don't know whether the connection interval can be greater than or equal to 20ms if the data transmission period of both parties is 20 ms.

The normal slave updates to the interval of 20ms, but according to the log, the slave's request to update the connection parameters failed, so the 15ms updated before the mobile phone was used. I don't know whether the connection interval can be greater than or equal to 20ms if the data transmission period of both parties is 20 ms.

Hi,

For the moment, I haven't managed to reproduce the issue on my side. Would you like to test the image I have built on your side to see if you manage to reproduce?

The image I have built is based on the data_stream example. Notifications are enqueued every 15 ms as soon as notifications for the service with UUID 0xF000C0C204514000B000000000000 is enabled (i.e. when writing 0x0001 to handle 0x0029).

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/data_5F00_stream_5F00_LP_5F00_EM_5F00_CC2340R5_5F00_freertos_5F00_ticlang.hex

Please let me know your findings.

Best regards,

Hi

Can you provide me with the source code for online debugging? I need to see the number of data sent by ble and the number of data received by mobile phone to confirm whether the data is abnormal.

Hi,

I have only modified the file app/Profiles/app_data_stream.c /cfs-file/__key/communityserver-discussions-components-files/538/app_5F00_data_5F00_stream.c

I hope this will help,

Best regards,

Hi

I put app_5F00_data_5F00_stream.c into the data_stream project, and the test showed more serious packet loss. I haven't found the specific reason yet.

Hi,

Ok, please let me know if you have results you would like to share so I can comment.

Best regards,