CC3100MODBOOST: Simplelink times out waiting for object

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;
}