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.

Urgent! CC3000 based Web Server: Debug version ok but Release version will not connect to Wireless AP

== Urgent! ==

Modified version of CC3000 FRAM Web Server Example has been ported to a 66 MHz, 32bit processor (Microblaze on Xilinx Spartan6 FPGA).
This is now fully functional on "Debug version", running on the FPGA

1) When executing "Release version" of the same code, the CC3000 no longer connects to the Wireless Access Point.
(This occurs even when the Release version is compiled with same GCC compiler Optimization and Debugger settings!)   

2) Operation of the functional "Debug version" is also not that robust.
ie. When subjected to successive mouse-clicks, occasional delays and errors are apparent in the browser user interface.

Question
I think the above 2 issues are possibly related and that the hard-coded delays within the code may be the problem area...
ie. in serverMain() [in httpserver.c] and main() [in webserver.c] 

Please advise what these delays need to be? (in time units not MSP430 clock cycles)
...and/or where else to look for resolution of this issue?

PS: The porting of CC3000 host driver software was done following the attached guidelines (received from- and discussed in detail with Gustavo Litovsky)

Thanks for your attention on this :-)
Peter Fenn 

2703.Notes from TI on porting CC3000 host driver software.pdf

  • It was the gcc compiler optimization setting that caused the “Release version” to fail.
    I’d set it to “Optimize for size” and this caused web server to fail and not connect to router.

    The 2nd issue remains:
    Please advise what delay-loops are needed and how long these should be for reliable webserver operation?

    Thankyou 

  • Peter,

         There is a new version of this sample application coming out soon. I think it removes the delay-loops. I am checking with the team and come back to you.

    Regards,

    Miguel

  • Miguel

    Can I please request early access to the mentioned new material?
    This is urgent, context is the the CC3000-based board being demo'd at Avnet's worldwide XFEST events right now

    Thankyou 

    Peter

  • Peter,

         I confirmed and there is a new feature in the host driver that indicates when all thje packets have been transmitted and therefore you dont have to wait in a loop. The release is coming out in around a week. Would that work?

    Regards,

    Miguel

  • Miguel

    Thanks for confirming that. Sooner than a week's time would be much better! :-)
    This board is being demo'd right now at XFEST events in Europe this week.

    Peter

  • Hi Miguel

    The new release is that only a new version of the cc3000 host lib ?

    or is it also a new firmware in the CC3000 ? if, yes is it possible to firmware update my Murata EM Board ?

    Kind regards

    Thomas

  • Thomas,

         It will be a change in the host driver and the CC3000 EEPROM. A tool and instructions to update it will be provided.

    Miguel

  • Miguel,

    Any update as to when this new version of the WebServer application will be available?

    I'm also waiting on Code Composer compatible source and project for the WebServer application.

    Please advise as to when this will be available.

    Thanks,

    Paul

  • Paul,

         We are wrapping up the packages currently. I expect they will come out sometime early next week. Thank you for your patience.

    Miguel

  • Miguel,

    Has the Code Composer version of the CC3000 FRAM WebServer app been posted yet?  I don't see a new version yet on the downloads page.

    Can you please provide a date when the CCS version of the CC3000 FRAM WebServer app will be available?

    Thanks,

    Paul

  • Miguel 

    Has that updated Webserver code been posted yet?

    Thanks

    Peter

  • All,

          We apologize for the delay. We are having some internal delays. Right now, estimated time line is late next week.

    Miguel

  • Miguel,

    It's been over two weeks since your last post.  Has the Code Composer version of the CC3000 FRAM WebServer app been posted yet?  I don't see a new version yet on the downloads page.

    Can you please provide a definite date when the CCS version of the CC3000 FRAM WebServer app will be available so that we can determine if we need to go with a different platform that has currently available support?

    Thanks,

    Paul

  • Hi Paul, 

    We are pending finalization of the patch programmer license, the patch will improve the first time configuration, but is not required to run the attached package, which includes the new version of the web server. It has a new host driver, and one of the added features is to send the TX complete after all packets have been acknowledged. This feature is utilized in the web server and will wait for tx completion after sending all the html pages, before closing the socket. 

    2728.CC3000_FRAM_webserver_2_0_16.zip

    Pedro 

  • Hi Paul, 

    Let us know if the package worked, we will post it in the wiki page shortly but will be nice to know if you have found any serious bugs.

    Pedro 

  • Hi Pedro,

    Thank you for providing the updated package with the Code Composer version of the MSP430 FRAM Webserver application.  I was able to successfully rebuild, load, debug, and execute the application under Code Composer V 5.2.  The application appears to runs successfully with no major problems.  However, I have noticed that the response time is slower for reloading the webpage than is was for the previous version of the webserver application.   There is a definite response time delay of about one second or more in between each successive reload of the webpage when using Internet Explorer V9.   I did not see this behavior with the previous version of the webserver; successive reloads of the webpage had no noticeable delay.

    - Paul

  • Hi Paul, 

    Yes I have seen this behavior, the TX complete event will arrive after all packets have been acknowledged, and that will ensure the web page is always displayed on your browser, the previous version delayed closing the socket after a fix period, but if you browser did not get all the packets the page will not display completely. So there is the option of using time delays or using the TX complete before closing the socket. 

    Pedro 

  • Hi Paul

    I have also a webserver running with a CC3000 module (Murata).

    Does Your webserver run stable over time ?

    I get stuck after serving a number of pages maybe 20, 40 or sometimes 60 pages to a client (meta tag with 30 sec. refresh)

    Kind regards

    Thomas

  • Hi Thomas, 

    Are you using the original code, or the one attached in this thread?

    Pedro 

  • Thomas,

    The new webserver app that Pedro posted in this thread seems to be stable over time, although web page reload times seem to be somewhat inconsistent.  The original webserver application was quicker to reload pages initially, but eventually would develop problems reloading the page or just hang up and have to be restarted.  I believe the webserver that relies on the transmission to be complete before closing the socket is a more robust implementation of the application.

    Paul

  • Hi Pedro

    I am using the Host lib attached in this thread.

    So I have the data sent acknowledge up and running but I still get stuck(not as often) after a while serving a client.

    I have not implemented the magic_byte stuff in the new spi_driver yet.......

    Kind regards

    Thomas

  • Thomas, 

    The magic_byte will detect a buffer overrun. It will be an indication to see if the packets are too big. The largest packet size I have seen when testing the web server are about 550 Bytes. And the TX,RX buffer size for the web server are about 800 bytes. 

    Where does the code gets stuck? 

    Pedro

  • Pedro,

    Thanks for this package, I could make it working on the default package.

    I have an issue with it: where is the continuous loop?

    I try to give the MCU a control task that can be monitored and eventually parametrized through the web application.

    He reacts very slow now, delay of up to 5 sec or more when I change an input.

    That was when I put the ref to the control procedure in

    hci_unsolicited_event_handler(void)

    But I assume that this is not directly where you should put this.

    Can you guide me?

    Gwen

  • Hi Thomas, 

    I tested the webserver 100 times in a row manually and did not fail. Then used the meta tag to refresh the web site every 10 seconds. and run it first 150 times and it stop refreshing, but I could reload the page. I did not capture the packets to see why it stopped to refresh. The second time I let it run it stopped after refreshing 500 times, again I could reload the page and turn on/off the light. 

    Which browser did you use, I tested with Chrome, who by the way keep requesting a favicon, so the web server refreshes twice. 

    BR,

    Pedro 

  • Hello,

    Can you share the code please? i have same issue and i could not resolve it.

    Thank you

  • Hi Burak,

    I used the code posted on the wiki (http://www.ti.com/lit/zip/swrc246). 

    How many iterations did you get. 

    Pedro

  • Thanks a lot Pedro it works fine. i have tried for 3 hours it worked well. I downloaded swrc246 before but the code stucks in an interrupt. But the code which is posted by you before that is called 2728.CC3000_FRAM_webserver_2_0_16.zip on the previous page, works well. I will try the code that you posted now.

    Thanks a lot

    Burak

     

  • Hello there

    Is there perhaps a 1.10.2 update to the HTTP Webserver Reference Design?  
    The last version noted was swrc246b (located under v1.9) 


    Thanks
    Peter 

  • Hi Peter,

    There has been some reorganization, and all example software should be posted on the CC3000 Wiki. There is a release going to come out relatively soon, but I do not have an ETA.

     

    Thanks,

    Aaron