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.

CC3000 ported to RL78G13 Issues with webserver



Hi

I am interfacing a CC3000 EM module via SPI from a RL78G13 5F100GL. I am working on IAR Workbench 1.10

My compiler memory settings are : stack 10k heap 2k

SPI channel running 8 MHz

SPI buffer setup :

void SpiOpen(gcSpiHandleRx pfRxHandler)
{
 sSpiInformation.ulSpiState = eSPI_STATE_POWERUP;
 sSpiInformation.SPIRxHandler = pfRxHandler;
 sSpiInformation.pTxPacket = wlan_tx_buffer;  
 sSpiInformation.pRxPacket = wlan_rx_buffer;
 sSpiInformation.usRxPacketLength = sizeof(wlan_rx_buffer);  // 4096 bytes
 sSpiInformation.usTxPacketLength = sizeof(wlan_tx_buffer);   // 4096 bytes
}

Everything is working fine, WLAN init, WLAN Scan, obtain IP with DHCP, get IPCONFIG info.

I also have a simple webserver running with a TINY webpage.

The webpage are served without problems when i keep the page under 300 chars. (My code is inspired from the LED WEB server example project for MSP430)

    sendHTTPData(cnum, HTTP_RESP, strlen(HTTP_RESP));   
    for(i = 0; i < strlen(indexPage); i += 300)   // Send the specificied page in chunks of 300 bytes empirically proven to be sendable        
    {
        if(strlen(indexPage) - i < 300)
        {
            sendHTTPData(cnum, &indexPage[i], strlen(indexPage) - i);
        }
        else
        {
            sendHTTPData(cnum, &indexPage[i], 300);
        }
       
        delayMilliSeconds(5);  // This delay is necessary, or else we run into issues
    } 

A webpage with a content > 300 bytes is served first time around, but second time around the API blocks ?

Another problem is when using recv  bytesRecvd = recv(cnum, requestBuffer, sizeof(requestBuffer), 0); This api function also blocks maybe the 2 problems are related.

It seems that my problems are related to transmission of larger packets to and from the CC3000 module ?

I am facing some other debug problems that has nothing to do with You, that prevents me from debugging deep in the API, so I am a bit stuck right now.

I hope that You can provide me some hints on what to look into....

Kind regards

Thomas Bødker

  • Hi Thomas, I suggest you set the Tx and Rx packet length to zero, since no packet has yet been sent or received.

     sSpiInformation.usRxPacketLength = 0; //sizeof(wlan_rx_buffer);  // 4096 bytes
     sSpiInformation.usTxPacketLength = 0; //sizeof(wlan_tx_buffer);   // 4096 byte

    Give that a try and let me know how it goes. My suspicion is that you are overwriting other memory locations.
  • Hi Staphae

    Thanks for your suggestion, I have changed my code to:

    sSpiInformation.usRxPacketLength = 0; 

     sSpiInformation.usTxPacketLength = 0;

    Problems are still the same . . . . . .

    Kind regards Thomas

  • ...My compiler memory settings are : stack 10k heap 2k

    How much RAM does the board you are using has? If i remember correctly, i think this board only has 4K of RAM. How are you able to link with the setting i referenced above when the board only has 4K RAM? I suggest you write a define byte pattern in TX/RX buffer at start up and also in the stack and see if they are overwritten during program execution. Otherwise i suggest you reduce your stack to about 1K . See if that helps.


    Regards,

    Staphae

  • Hi Staphae

    It is a special developed board that we made for our demo application. It has a Renesas RL78G13 type R5F100GL MCU with 32K RAM so that should be enough memory for running a small webserver. I will try out Your suggestions tommorrow.... thanks !

    Kind regards

    Thomas

  • Hi Thomas, 

    Could you explain what you mean by the api function "blocks". In the current driver most of the API functions are blocking, only a few are asynchronous. Does the function never returns? 

    BR,

    Pedro

  • Hi Pedro

    Yes, I know that the functions are blocking right now.

    In my case it never return. it is especially send and recv that causes the trouble. send works if I send small amount of data, recv blocks totally and never returns.

    I think it is strange, when alot of other API functions are working fine. WLAN status, connect, DHCP and send(works a little)

    I have other issues regarding debug right now that has nothing to do with CC3000,  that prevents me from debugging deep into the lib, so I hope that You had a hint,

    maybe some buffer is to small, running to slow on SPI, etc.

    Kind regards

    Thomas

  • Hi Thomas,

    Are you able to receive any data at all? or do you get stuck on the first "recv" function call?

    If the first time works for you, can you please try to close the socket and then open + accept on it before the next recv call?

    Thanks,
    Alon.S

  • Hi Alon

    The recv function doesn't function at all.

    I get stuck down in the API and that a shame because my webserver demo should be able to take some params from the client.

    So the receive part is "commented out" right now.

    But basically I do as You say :

    1: Listen

    2: accept

    3: recv (not working therefor commented out)

    4: send (only small amount of data)

    kind regards

    Thomas

     

  • Hi Thomas,

    Can you please post the relevant code parts of both sides (client & server).

    In addition, Are you able to capture wlan sniffer capture of this sequence? (with no security, so I can parse the data).


    Thanks,
    Alon.S

  • Hi Alon

    Thanks... Here I send my complete IAR Workbench project.

    It is in the webserver.c that i get stuck.

    7041.wifi_RL78.zip

    My client is a laptop with IE and sometimes an iPhone with Safari.

    I do not have a WLAN sniffer device yet.

    Hope You can figure out what I am doing wrong.........

    Kind regards

    Thomas

     

  • Thanks.

    I'll have a look and get back to you.

    Alon.S

  • Hi Alon

    I really appreciate Your help!

    I have been able to debug down to where I get stuck in recv. 

    I reached SimpleLinkWaitData and got stuck in the hci_event_handler function where if (tSLInformation.usEventOrDataReceived != 0)

    Does this make sense ?

    Kind regards Thomas

  • Hi Alon

    Have You looked into my code ? or do You have some hints for me ?

    kind regards

    Thomas

  • Hi Thomas,

    I didn't see any problems with your code.

    I suspect that maybe the HTTP client on the other side closed the socket after sending the data, are you able to confirm\deny that?
    If you are able to send me sniffer capture I will be able to verify it. 

    If that is the case, then we might have a bug in which if a socket is closed then we can't read the data that was transmitted from that socket.
    I'm currently looking into that possibility. 

    Thanks,
    Alon.S 

  • Hi Alon

    I have tried to capture the situations with wireshark.

    Client IP 192.168.1.106

    CC3000 device IP: 192.186.1.111

    First capture is a startup, DHCP routine and shows the CC3000 device serving small webpage to an Internet explore on 192.168.1.106. The simple page is served 7 times with a few seconds pause and then it chrashes.

    5466.simple_webserver_capture.zip

     

    Second capture is startup, DHCP and recv() function in "action" .

    5037.capture_with_RECV.zip

     

    I hope this can help You.

     

    Kind regards Thomas

  • Thanks Thomas,

    I'll review it and get back to you.

    Regards,
    Alon.S

  • Hi

     

    Could it be an idea to connect to the CC3000 low level debug_uart ? What kind of info is available there ?

     

    I would really like some answers/hints soon, time has become an issue . . . . . .

    Whats up with the SW release, that should have been released 2 weeks ago ?

    kind regards

     

    Thomas

  • Hi Thomas,

    You will not be able to use the debug_uart as we are using a proprietary logger for it.

    I'll try to push on providing some hints regarding your issue, sorry for the delay.

    The release would be available soon.

    Thanks,
    Alon.S

  • Hi Alon

    Again thank You for spending Your time on us yesterday.

    I have begun writing the SPI driver myself based upon your porting specifications along with Your MSP430 code.

    Meaning that the RL78G13 example code from third party company is out off the project.

    After removing the delay in the send receive function, I got the RECV() function working :-) ! !

    void CC3000_SendReceiveData(unsigned char *txbuf, unsigned short txnum, unsigned char *rxbuf)
    {
      g_csi21_tx_count = txnum;  /* send data count */
      gp_csi21_tx_address = txbuf; /* send buffer pointer */
      gp_csi21_rx_address = rxbuf; /* receive buffer pointer */
      while(g_csi21_tx_count)
      {
       SIO21 = *gp_csi21_tx_address; /* started by writing data to SDR[7:0] */
       gp_csi21_tx_address++;
       g_csi21_tx_count--;
       /* Wait until end of TX */
       SPIWaitForTxFinish();
       *gp_csi21_rx_address = SIO21;
       gp_csi21_rx_address++;
      }
      //SysCtlDelay(1000);
    }

    And I almost have the send() working aswell. I actually think that if I do not delay enough after last send() I might be closing the client socket to soon.

    Delay has to be greater than approx. 500 mS.... What is Your oppinion on my assumption ?

     

    So actually we have solved the issues for now :-)

     

    Kind regards

    Thomas

  •  Hi Thomas,

    Good to hear that you have managed to pass your major barrier.

    Indeed, some delay is required between send() and close().
    However it is hard to tell how much is enough, since it depends on the packet length, number of packets and the WLAN rates in which the packets are transmitted.

    In our upcoming release, we’ve added an unsolicited event of Tx_complete, signaling the application on the end of a successful transmission.

    Thanks,
    Alon.S

  • Hi Alon,

    I was trying to create a simple web server using CC3000EM with MSP340FR5739 board. I was using Basic wifi application code in IAR examples and came across same bug. recv function is not returning a value. Just wanted to know if there is a newer version of drivers available which fixes this bug?

  • Hi,

    1. Before running your web server code, did you trying runining the basic WiFi example to make sure your HW\SW setup is working with no issues?

    2. In your web server application, did the accept() API passed succesfully? please note that in default the accept() is non blocking and will return -2 if no connection is established. You need to make sure that you've received a valid child socket number, before trying to receive packets on that socket.

    Thanks,
    Alon

  • Hi,

    Basic wifi application is running fine. I was able to connect to my wifi network and can ping the device. accept() function is working and it assigned a child socket number. The problem is with the recv() function. It would block the program flow and does not return anything.

    Thanks.