This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi Martin,
At present there are no ways to directly handle the internal memory of CC3000. At user level we can only wait till there are buffers available for Tx.
Is it that when the issue happens, the available buffer event is not reported to the user by 'HCI_EVNT_DATA_UNSOL_FREE_BUFF' event? Does it always show '0' as the value for 'tSLInformation.usNumberOfFreeBuffers' in the evnt_handler.c?
Do you see ARP activity during your test case? Can you please share the air trace if possible? At any point in your code are you making a call to netapp_arp_flush?
Thanks & Regards,
Raghavendra
Nr: 770
Number of buffers left = 3
Nr: 771
Number of buffers left = 2
HCI Event Free buffert!
Nr: 772
Number of buffers left = 3
Nr: 773
Number of buffers left = 2
HCI Event Free buffert!
Nr: 774
Number of buffers left = 3
Nr: 775
Number of buffers left = 2
HCI Event Free buffert!
Nr: 776
Number of buffers left = 3
Nr: 777
Number of buffers left = 2
Nr: 778
Number of buffers left = 1
Nr: 779
Number of buffers left = 0
Nr: 780
No more buffers left = 0 (No more transfers done)
Hi Martin,
Thanks for the information. I was just trying to rule out any of the ARP activities. Can you please share the capture that you already have?
Also, do you see a change in behavior when the buffer size is reduced from 1440? Does the system recover after sometime with 'HCI_EVNT_DATA_UNSOL_FREE_BUFF' and making buffers available? Or once it hangs, is it forever?
Thanks & Regards,
Raghavendra
Hello Raghavendra, I have tried to inserted a Wireshark capture that contains all information from the startup to the CC3000 stops transmiting. What file ending should it have? I tried using .pcapng.
The system responds after the transfers but will never send any more information over the CC3000. It uses HCI_EVNT_DATA_UNSOL_FREE_BUFF from time to time but it stopps working after a set of transfers.
Below are the amount of packages sent according to tSLInformation.
CASE 1:
Send Packages: 781
Released Packages: 775
Size: 1440
CASE 2:
Send Packages: 1556
Released Packages: 1550
Size: 720
Martin,
You have run into the same issue as a lot of us have here within the past 2 months and there seems to be no way around it. TI says they are looking into it and will respond to a new post but the support will soon cease once they can't figure it out. This issue presents itself in many different ways, UDP, TCP and MDNS, you always eventually run out of buffer to send data.
I wish we could really figure this out already. If you can provide a debug trace to them from the debug pins that may help, I personally did not route them out from under the module on my pcb so I cant do it. TI are you actively looking into why the buffer keeps running out? I eventually gave up and moved on hoping they are going to figure it out and release a patch soon.
So TI I asked before what we could do to help troubleshoot this issue and never got a response even though many people wrote in they agreed and wanted a response. Can we get a clear answer on what is going on with this issue? Are the design engineers currently working on it or do you still have low level engineers trying to figure it out? Is there anything we can do to help? Like trying different settings? Looks like you suspect ARP, mind sharing why? I personally have set all my socket timeouts to infinite so I can handle it myself, could this be a problem? Are any resources being used to fix this or has everything moved over the design of the new CC3100 we keep hearing rumors about? Is the new module going to be pin compatible with the CC3000?
TI, ARE WE ALL JUST WASTING OUR TIME WITH THIS MODULE OR WHAT?
Right from the home page of the CC3000 Wiki, "The main goal of this wiki is to be the first line of support and information for all customers and users of this platform". Where is the second line of support because I need to talk to them! No offense to the guys helping in the forum but we need advanced support on this issue as it is a clear SHOWSTOPPER and has been kicking around for at least 2 months.
Chad
Hi Martin,
Looks like the traces are missing. But as I understand, the internal buffer is getting filled and the host has to wait until you get the unsolicited event for a long time and when it comes, the subsequent transfers result in loss of data. And the recovery does happen eventually right? And it does not hang, right?
Would you be able to provide us the logger logs from debug pins?http://processors.wiki.ti.com/index.php/CC3000_Logger
Hi Chad,
We are tracking few issues related to the memory overflow. All these issues may not have the same root cause. Hence we would either have to identify them based on the symptoms of the issue, to understand if they are similar to other issues that we have already observed. Or we request for the debug logs from the debug pins, which is a better way get the issue solved. Hence we request you to provide these debug logs to proceed with efficient debugging.
Thanks & Regards,
Raghavendra
Hi Raghavendra,
> Hence we would either have to identify them based on the symptoms of the issue
> to understand if they are similar to other issues that we have already observed.
it would all be a bit easier, if one or multiple test versions of a patch are released. Then you would see what is already fixed and what is still open and must be fixed in a different way. Or add debug events if you run in certain situation (like a crash dump) which a customer can report to TI.
Do small steps. Do transparent communication. Then a customer will understand, why it takes so long. I am still missing a (planned) release date for something new (let it be a test or even an official release). There is even no info, if there will be a release at all in near future or CC3000 is suddenly marked as NRND (Not Recommend for New Designs).
When you do a big step and not fix all errors, do you think customers will wait again till remaining errors are fixed, after waiting for (more or less) 4 month?
I know it is not your problem, you do the best to give support here in the forum. Many thanks for it!
Forward it to the TI department, which is responsible for planning the releases.
Just my 2 cents...
Best regards,
Martin
Raghavendra,
First thanks for replying but your reply helps me 0%. I asked many questions in the post and you could not answer any of them, all you can do is give the canned response of we need debug logs which in your words, "which is a better way get the issue solved", ok but it is not the only way. I have asked for advanced technical support and all I get is the same bullshit. Well I am done. I am moving on to Bluegiga as their modules are similar in price and they actually work hopefully.
Martin, Sorry to jump in on your post, good luck, you are going to need it, we are all going to need it.
Hi,
I posted the same issue in the thread "CC3000 sometimes takes long time to release TX buffer" 3 months ago and no answer. I don't know if TI guys do not care or they are not able to resolve the issue. I think and suggest TI should hire better engineers. I'm so surprised TI's management team's altitude.
Thanks
Instead of using TCP, I change my design to use UDP and it does solve the issues for my application. However, I do worry if TI will discontinue this product in the near future.
Martin, Joo Hong, Chad,
First, we are very sorry to hear about your experince with the product and support.
We understand and acknowledge the issues you have high-lighted on this and a couple of other threads.
I wanted to let you know that we are analyzing these issues and working to understand the root cause.
We plan to come back to you shortly with outcome of the analysis and next steps.
Thank you again for high-lighting the issues, we will keep you updated on our progress and findings.
Adnan
Hi Adnan,
Has this issue been resolved? Will there be an API for forcing buffer clearing? I am running into this issue as well. I can see the amount of buffers slowly dwindle. Even after waiting for a long time I do not see the HCI_EVNT_DATA_UNSOL_FREE_BUFF.
It seems that HCI_EVNT_DATA_UNSOL_FREE_BUFF is only fired after socket writes, however it fires less frequently than the actual sockets that are being written.
It also seems that the buffers are not cleared after the socket closes. So if the buffer does not free before the socket closes, then that buffer is never recovered.
I upgraded to driver 1.14 and since then I haven't had HostFlowControlConsumeBuff() hang forever waiting for a buffer.
I did then start to have failures in where it hung in hci_event_handler(). It appears to be this issue: https://e2e.ti.com/support/wireless_connectivity/f/851/p/312391/1167512
There a fix in my code base that was done by a previous engineer. The change is commented with "fix from forums" but without a link I can't figure out where exactly it came from.
Anyway, that fix was: Remove the line tSLInformation.usRxEventOpcode = usOpcode; from SimpleLinkWaitEvent() and add it to hci_command_send() just before the SpiWrite call. This looks like:
UINT16 hci_command_send(UINT16 usOpcode, UINT8 *pucBuff, UINT8 ucArgsLength) { UINT8 *stream; stream = (pucBuff + SPI_HEADER_SIZE); UINT8_TO_STREAM(stream, HCI_TYPE_CMND); stream = UINT16_TO_STREAM(stream, usOpcode); UINT8_TO_STREAM(stream, ucArgsLength); // moved from Simplelinkwaitevent() tSLInformation.usRxEventOpcode = usOpcode; //Update the opcode of the event we will be waiting for SpiWrite(pucBuff, ucArgsLength + SIMPLE_LINK_HCI_CMND_HEADER_SIZE); return(0);
}