• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 40 subscribers
  • Views 791 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3200 HTTP server very slow after MAP_SPIConfigSetExpClk called

Duncan Gray
Prodigy 80 points
Other Parts Discussed in Thread: CC3200MOD, CC3100, CC3200

Using Out of Box example on a Redbearlab WifiMini board. (Uses CC3200MOD)

Server in STA mode

Testing server response time in Google chrome dev tools I get ~ 18ms response time when fetching a param file containing a single token.

After I activate the SPI interface, that response time drops to several seconds.

Relevant code below:

1st, the param file 

<html>
<body>
<p id="gsr_nval">__SL_G_UNE</p>
</body>
</html>

The code which returns data for the token...

if(memcmp(pSlHttpServerEvent->EventData.httpTokenName.data,
GET_token_TEST, strlen((const char *)GET_token_TEST)) == 0)
{

short sTempLen = itoa(123,(char*)ptr);
pSlHttpServerResponse->ResponseData.token_value.len += sTempLen;

}

And finaly, the SPI init code...

//
// Reset SPI
//
MAP_SPIReset(GSPI_BASE);

//
// Configure SPI interface
//

MAP_SPIConfigSetExpClk(GSPI_BASE,MAP_PRCMPeripheralClockGet(PRCM_GSPI),
SPI_IF_BIT_RATE,SPI_MODE_MASTER,SPI_SUB_MODE_1,
(SPI_SW_CTRL_CS |
SPI_3PIN_MODE |
SPI_TURBO_OFF |
SPI_WL_8));

//
// Enable SPI for communication
//
MAP_SPIEnable(GSPI_BASE);

//
// Print mode on uart
//
Report("Enabled SPI Interface in Master Mode\n\r");

 

My pin_mux file relevant section

void PinMuxConfig(void)
{
//
// Enable Peripheral Clocks
//
PRCMPeripheralClkEnable(PRCM_UARTA0, PRCM_RUN_MODE_CLK);
PRCMPeripheralClkEnable(PRCM_GSPI, PRCM_RUN_MODE_CLK);
PRCMPeripheralClkEnable(PRCM_GPIOA1, PRCM_RUN_MODE_CLK);
PRCMPeripheralClkEnable(PRCM_GPIOA2, PRCM_RUN_MODE_CLK);
PRCMPeripheralClkEnable(PRCM_GPIOA3, PRCM_RUN_MODE_CLK);

//
// Configure PIN_55 for UART0 UART0_TX
//
PinTypeUART(PIN_55, PIN_MODE_3);

//
// Configure PIN_57 for UART0 UART0_RX
//
PinTypeUART(PIN_57, PIN_MODE_3);

//
// Configure PIN_05 for SPI0 GSPI_CLK
//
PinTypeSPI(PIN_05, PIN_MODE_7);

//
// Configure PIN_06 for SPI0 GSPI_MISO
//
PinTypeSPI(PIN_06, PIN_MODE_7);

//
// Configure PIN_07 for SPI0 GSPI_MOSI
//
PinTypeSPI(PIN_07, PIN_MODE_7);

//
// Configure PIN_63 for GPIO Input
//
PinTypeGPIO(PIN_63, PIN_MODE_0, false);
GPIODirModeSet(GPIOA1_BASE, 0x1, GPIO_DIR_MODE_IN);

//
// Configure PIN_03 for GPIO Output
//
PinTypeGPIO(PIN_03, PIN_MODE_0, false);
GPIODirModeSet(GPIOA1_BASE, 0x10, GPIO_DIR_MODE_OUT);

//
// Configure PIN_08 for GPIO Output
//
PinTypeGPIO(PIN_08, PIN_MODE_0, false);
GPIODirModeSet(GPIOA2_BASE, 0x2, GPIO_DIR_MODE_OUT);

//
// Configure PIN_53 for GPIO Output
//
PinTypeGPIO(PIN_53, PIN_MODE_0, false);
GPIODirModeSet(GPIOA3_BASE, 0x40, GPIO_DIR_MODE_OUT);
}

 

I do not believe it is the Redbearlab WifiMini board at fault.  It seems more like an internal conflict of sorts.

Can someone shed some light on this problem?  Is there some other parameter I should set to get things going smoothly?

  • 0
    Prodigy 80 points
    More info: I read somewhere that CC3200 uses SPI to communicate between the M4 mcu and the onboard CC3100.

    Is that the cause of the conflict? How to fix it?
  • 0 in reply to Duncan Gray
    TI__Genius 16370 points
    Allow me to review your code snippet and get back.

    -/Praneet
  • 0 in reply to Praneet Kumar
    Prodigy 80 points
    Thank you. FYI I have a webpage with javascript call to fetch that token every 40ms. Without SPI active, it takes ~18ms.
    Activate SPI as above and it stops responding.
  • 0 in reply to Praneet Kumar
    Prodigy 80 points

    I wrote my own SPI functions so that I could eliminate the built in SPI as the problem.

    The problem still exists.  Testing has shown that just toggling a GPIO port and then not touching it again, is enough to slow the server response from ~18ms to ~58ms permanently. 

    What I mean by that is, I am not continuously toggling the port, it is a one time toggle, but it has a permanent effect on the server response time.  The response is then too slow, exceeding my 40ms requirement which causes the server queue to fill up and become unresponsive.

    I have to conclude that this product does not measure up to my requirements.  Perhaps a future system update can improve things.