CC3100 hang in sl_send with buffer size lager than 1024 bytes

Hi TI 

I am working on a project combine CC2650 and CC3100 (BLE-Wifi) 

Currently, Host driver porting is working properties, I think. 

But when I make a quick check with TCPSocket application. I seen something wrong with it. 

When using sl_send API to send buffer data with Length > 1024 byte (like  1100, 1200,1400 bytes) the application will hang in 

VERIFY_PROTOCOL(SyncCnt < SL_SYNC_SCAN_THRESHOLD); after more than 10 time send success (have check with WireShark ) 

which is come from _SlDrvMsgReadSpawnCtx. Seeing in call stack I saw Host device receive interrupt and perform a read action and waiting for SYNC_PATTERN_LEN from device. But it could not get the SYNC_PATTERN_LEN. 

In this case, I think 2 position things can happen:

1. My host driver didn't working properties

2. CC3100 didn't send the SYNC_PATTERN_LEN to host device

I performed some more testing. by check the BUFF_SIZE to lower or equal 1024 bytes.

With BUFF_SIZE <= 1024 bytes. The application working fine.  (With 20000 times send success) 

Environment test: 

- CC3100BOOST Ver 4.0 

- SmartRF06EB - CC2650 7ID 1.2 

- CC31000 Service pack 1.0.0.1.1

- CC31000 Host driver 1.1 

- TCP server : IPert3 (Window) 

 

Hi,

Can you please share the wireshark logs (both success & failure) ?

Regards,
Gigi Joseph.

Hi Gigi, 

Thank you for your quick rely 

Wireshark log included: 

- 1024 bytes success (1000 times transmit) 

- 1200 bytes fail 

- 1400 bytes fail 

WiresharkLogs.rar

Hi Gigi, 

More information, hope it help. 

I had checked the log file and found than in the last send TCP packet. Iperf send ACK respond is longer than another. So, i configured the receive time out socket with 10 sec by code: 

    struct SlTimeval_t timeVal;
    
    timeVal.tv_sec =  10;             // Seconds
    timeVal.tv_usec = 0;             // Microseconds. 10000 microseconds resolution
    
    sl_SetSockOpt(SockID,SL_SOL_SOCKET,SL_SO_RCVTIMEO, (_u8 *)&timeVal, sizeof(timeVal));    // Enable receive timeout 
  

For now. The driver is hang around code below. 

    /*  6. Scan for Double pattern. */
    while ( N2H_SYNC_PATTERN_MATCH(pBuf, g_pCB->TxSeqNum) )
    {
        _SL_DBG_CNT_INC(Work.DoubleSyncPattern);
        NWP_IF_READ_CHECK(g_pCB->FD, &pBuf[0], SYNC_PATTERN_LEN);
    }

Hi Gigi 

Have you any update ? 

For helping, I update some value information for the issue. I think some problems in cc3100 are the reason of the issue 

I have check in Logic analyst to investigate what it is. I found than After send the Sync Word (Host to device,Read: 0x8765567x ) CC3100 doesn't send the SyncWord(0xABCDDCBx ). 

Please check It and confirm about the issue. 

The bellow is the capture of logic analyst. I also attach the logic analyst data. You can download and install logic analyst at here 

Thanks and best regards, 

Kevin 

CC3100_LogicAnalyst_1400B_Fail.rar

Hi Vu,

Several comments:

1. Can you please update to the latest host driver and SP?
 Host driver: 1.1.0
 SP: 1.0.0.10.0

2. What is the SPI clock speed that you are using? can you please try a lower SPI speed? (1Mb)

3. Are you using your SPI DMA, can you try working without it?

4. What is your host processor?

Thanks,
Alon

Hello Alon 

Thank you for your respond. 

1. Can you please update to the latest host driver and SP?

By the way, Did you even read my post carefully. 

I told my environment test are bellow in the the post abow

- CC3100BOOST Ver 4.0 

- SmartRF06EB - CC2650 7ID 1.2 

- CC31000 Service pack 1.0.0.1.1

- CC31000 Host driver 1.1 

- TCP server : IPert3 (Window) 

2. What is the SPI clock speed that you are using? can you please try a lower SPI speed? (1Mb)

You can check in my logic analyst (attached in the my last post).

YES, THE FREQUENCY IS 1MHZ 

3. Are you using your SPI DMA, can you try working without it?

Yes, I am using SPI DMA. And I can't try working without it because that seem CC2650 only support SPI DMA.

4. What is your host processor?

Again, I am working on a project combine CC2650 and CC3100 (BLE-Wifi) 

Yes, MY HOST PROCESSOR IS CC2650 

Best regards, 

Kevin 

 

Hi Kevin,

Sorry about that, I missed your initial posts.
Our host driver doesn't have any problem handling any size of packet.
Packets above ~1400bytes will be fragmented, but this is all handled by the CC3100 driver.

Having problems with packets bigger than 1024 bytes is strange and we didn't see such an issue before.
I'll talk with my colleagues from CC2650 team and get back to you asap.

Thanks,
Alon

Hi Kevin,

The CC2650 uDMA has a threshold of 1024 bytes on the DMA transactions. Can you please send me your source files related to uDMA and SPI ?
I believe you might need to have code handling the SPI operations over 1024 bytes.

Thanks,
Alon

Hi Alon.

Yeah, thank you for your quick reply.

Ok. Please give me your email.

Anyway, do you have any explain for the issue missing Sync Word in my logic analyst above.

And if the issue relate to spi dma. Why did i can perform   transmitted 10 times successfull .

Best regards.

Kevin

Send form my tablet. Can not logging to ti forum form my web browser

Hello Alon,

I appreciate your suggestion,

I checked again my SPI implement. Yes, as you said CC2650 SPI DMA has a threshold of 1024 bytes. And I didn't handle the threshold.

I fixed it by break the TCP packet with the size > 1024 in to multiple pieces with SIZE  type ( SIZE  = 1,256,512,1024 byte). And send until all bytes is transmitted.  

Now, The result is good so far. But the issue still there.

With  20000 times transfer 1400 bytes data through TCP (CC3100 TCP client -> Iperf TCP server)

SIZE                                     Status

1 byte              ->                Good 

256                    ->                 Fail

512                    ->                 Fail

1024                    ->               Fail

Notice than the result is better than the older version. Host driver is only hang after few thousand times transfer success. Sometime all of SIZE is transfer successfully. 

I performed a double check with code (example code) of TI. And see in spi_write() of TI.

Understanding than TI perform transfer byte by byte to SPI channel to transfer to CC3100.

I make me think about there

-  Might CC26500 SPI DMA dump data to fast -> CC3100 missing something from host ?

- SPI connection is not good between SmartRF06 board <-> CC3100

I need an confirm from TI about the interval between 2 bunch clock of two bytes

In my case, the interval is 2 us. 

Really hard to debug the issue. Appreciate with any infor

THank and best regards,

Kevin  

Hello Alon, 

I have attached my SPI code. Please take a look 

Today, I tried to investigate more in the issue. 

I think my connection between CC3100 and SmartRF06 is not good. Maybe, it is too long for transfer data fast. 

Quick fix by shorter the connection and make it stable than before. The result is better. In all case. 

The stress test are: 

200 000 times transfer TCP packet from TCP client (CC3100) to Host (Ipertf) 

With two type of transfer: 

SPI Speed 1Mhz and 500 Khz 

THe result: 

with 500Khz -> I need to run the test over 1 h to see the issue happen 

With 1Mhz -> It's better than the older connection. But the issue still there. 

I also attach Wireshark and logic analyst log data at here. Only have Log data with 1Mhz because it's easy to reproduce. 

Thanks and best regards, 

Kevin 

spi_source.rar

Hi Alon,
Did you even try to stress test like above with DMA SPI have speed fast as the test ?
And Do you have any update at my case ?
Best regards,
Kevin