CC3100MODBOOST: Simplelink times out waiting for object

Part Number: CC3100MODBOOST
Other Parts Discussed in Thread: CC3100

Hi again,

Porting the simplelink driver to STM32.

I got the SPI communication working, and sometimes I would get the module to connect, but most of the time (seems timing related) i get a driver error while waiting for response. Here is the SPI log:

 >65 >87 >78 >56 <0 <bc <dc <cd <ab <8 <0 <8 <0 <0 <0 <0 <0 <11 <11 <11 <11 >21 >43 >34 >12 >85 >8c >4 >0 >0 >0 >0 >0

Attached is scope traces of the last SPI bytes tx/rx (scope lines are CS, clock, mosi, miso). Watching the scope, there is no IRQ after this sequence. (RxIrqCnt==1) What is going wrong?

Download Attachment

Available until May 28, 2021

The command that times out is  sl_WlanProfileDel

  • i tweaked my spi code and got it to work.

  • But then when i test with different encryption methods the issue comes back. I would like to understand what is is that causes these timeouts? 

    SPI LOG for this problem: >65 >87 >78 >56 <bc <dc <cd <ab <8 <0 <8 <0 <0 <0 <0 <0 <11 <11 <11 <11 >21 >43 >34 >12 >85 >8c >4 >0 >0 >a >0 >20 >65 >87 >78 >56 <bd <dc <cd <ab <85 <c <8 <0 <38 <0 <0 <0 <0 <0 <11 <11 >21 >43 >34 

    this is not the whole log, but i suppose the problem is with SPI bus timing not with the data sent.

  • Hi,

    It is unlikely that the encryption code you're using is the cause of your SPI issue, but rather the SPI interface porting layer itself.

    If you are porting from the CC3100 SDK, have you taken a look at the reference STM32 port? It is for the stm32f4xx devices, but the HAL can still be useful as a reference.

    I'm curious, what were the tweaks you made that originally appeared to have fixed the issue? I suggest keep looking at your SPI porting code as well as the rest of your HAL - the CC3100 is tested to work over the SPI interface at up to 20MHz without issue, and thus the problem is likely to be in either your porting code or maybe the hardware setup you have between the CC3100 and your STM32.

    Regards,

    Michael

  •  Where can I find the reference STM32 port? I doubt i could use it because the HAL layer is too complex but I can look at the SPI code.

    Here is my SPI code. It is interesting that the only difference between the bytes sent for Open network and WPA2 network (which is my iPhone 11 hotspot), is the SSID name and security type. in both cases i send the key and in both cases number of characters in SSID is the sam. So it's not the number of bytes in the transfer but rather the contents of the command sent. 

    int sl_IfRead(_SlFd_t fd, unsigned char *pBuff, int len)
    {
    main_disable_all_interrupts();
    SPI_CS_HI();
    SPI_CS_LO();
    for (UINT16 i=0; i<len; i++)
    {
    while ((SPI1->SR & SPI_SR_TXE) == 0);
    SPI_TX(0);
    while ((SPI1->SR & SPI_SR_RXNE) == 0);
    pBuff[i] = SPI_RX();
    QuietenWatchDog();
    }
    SPI_CS_HI();
    main_enable_all_interrupts();

    if (log_spi) for (UINT16 i=0; i<len; i++) wifi_spi_log(1, pBuff[i]);
    return len;
    }

    int sl_IfWrite(_SlFd_t fd, unsigned char *pBuff, int len)
    {
    main_disable_all_interrupts();
    SPI_CS_HI();
    SPI_CS_LO();

    for (UINT16 i=0; i<len; i++)
    {
    while ((SPI1->SR & SPI_SR_TXE) == 0);
    SPI_TX(pBuff[i]);
    while ((SPI1->SR & SPI_SR_RXNE) == 0);
    (void)SPI_RX();
    QuietenWatchDog();
    }
    SPI_CS_HI();
    main_enable_all_interrupts();

    if (log_spi) for (UINT16 i=0; i<len; i++) wifi_spi_log(2, pBuff[i]);

    return len;

  • Also I am suspicious about the CS line, as I am driving it through GPIO. CS is initially high until the first transfer, (also tried having it initially low), then it stays high until next transfer. In open network, I can get as far as opening a server socket and I have no comm errors.

  • here is the SPI init code:

    void main_spi_register_v(void)
    {
    BIT_SET_M(RCC->APB2ENR, RCC_APB2ENR_SPI1EN);

    SPI1->CR1 = (SPI_CR1_MSTR | SPI_CR1_SSI | SPI_CR1_SSM | SPI_CR1_BR_1 | SPI_CR1_SPE)
    & ~(SPI_CR1_BIDIMODE | SPI_CR1_RXONLY | SPI_CR1_DFF | SPI_CR1_CPOL | SPI_CR1_CPHA | SPI_CR1_LSBFIRST | SPI_CR1_CRCEN);

    SPI1->CR2 = 0;
    }

  • Hi,

    I am not familiar with the STM32 low-level SPI registers and driver code, so I can't tell what might be wrong with your implementation. I suggest you contact STM support for assistance regarding the STM32-specific code.

    As for the existing porting STM32 porting files, you can find them in cc3100-sdk/platform/stm32discovery of the CC3100 SDK. I suggest you use those as a reference for your porting code.

    Still, it seems strange that you run into your issue when performing different networking software tasks. In theory, if you can have your code work fine in an open network, then there shouldn't be any SPI interface issues, as those would have appeared earlier during your code execution, most likely during sl_Start() itself.

    Have you checked your RTOS state when the error occurs, to ensure that there isn't some RTOS error or other higher-level error causing your issue?

    Regards,

    Michael

  • The timeout constants for NonOS needed to be scaled