Thanks Tomar,
I have a few more update on this issue.
In current situation I can able to do the communication in one direction without any problem, means at a time if I am doing only one operation then there is no issue.
Like if CC3000 keep on receiving a data from PC then it will work without any problem with high data rate(~2Mbps) and the same is true when CC3000 only sending a data to PC continuously without any delay in between two send operation.
But when I am making a loop type of application in which PC is sending a data to CC3000 then CC3000 sending back to PC then after some time it will reset the adapter and it seems like some memory violation issue to me, it does not stop in very first loop but it hit this condition after certain amount of time and if I will increase the time delay between two send operation in PC side then I can see better performance and it works for a long time, with the use of 150 ms delay in between two send operation in PC application I have seen it works for a long time and in this case it does not even reset the adapter but it hangs somewhere in host driver.
Do you think changes made in V1.11 can help us to resolve the issue, if you can send me the patch before official release, only for testing then I can verify if this changes fix the issue.
I am using freescale micro-controller - MCF5253
I have already made one change in CC3000 to work with our compiler environment, after making this change I can able to Tx and Rx data in one direction.here is the change done by me:
unsigned
shortSTREAM_TO_UINT16_f(char* p, unsignedshortoffset)
{
//return (unsigned short)((unsigned short)((unsigned short)(*(p + offset + 1)) << 8) + (unsigned char)(*(p + offset)));
return (unsignedshort)((unsignedshort)(((unsignedshort)(*(p + offset + 1)) << 8) & 0xFF00) + ((unsignedshort)(*(p + offset))& 0x00FF));
}
unsigned
longSTREAM_TO_UINT32_f(char* p, unsignedshortoffset)
{
//return (unsigned long)((unsigned long)((unsigned char)(*(p + offset + 3)) << 24) + (unsigned long)((unsigned char)(*(p + offset + 2)) << 16) +
//(unsigned long)((unsigned char)(*(p + offset + 1)) << 8) + (unsigned long)((unsigned char)(*(p + offset )) << 0));//(unsigned long)((unsigned long)(*(p + offset))));
return (unsignedlong)((unsignedlong)(((unsignedlong)(*(p + offset + 3)) << 24) & 0xFF000000)|
+ (unsignedlong)(((unsignedlong)(*(p + offset + 2)) << 16) & 0x00FF0000)
+ (unsignedlong)(((unsignedlong)(*(p + offset + 1)) << 8) & 0x0000FF00)
+ (unsignedlong)(((unsignedlong)(*(p + offset )) << 0) & 0x000000FF));
}
If I don't do this change then it will modify the value to very high value when working on (unsignedlong)(((unsignedlong)(*(p + offset )) << 0) & 0x000000FF));
Suppose it has E8 in this to convert then without this change the output was 0xFFFFFFE8, so to prevent from this condition I need to change this.
Do I need to make any other similar type of changes to make the host driver compatible to Freescale?
Also I am using a latest patch version 1.11.7.12.14 and using a host driver of 1.10.6.11 cause changes made in 1.11.712.14 was creating a problem in transmitting a data from CC3000 to PC and resetting the device(Memory exception issue)