We are using a murata SN8000 module connected via SPI mode 0 operating with 25Mhz to a cortex m3 lpc1837. We are using a WWD ported from the SDK 3.1.2 (including matching patch from murata). We are using a custom PCB with SPI Flash, SDRAM, MSU and SN8000. The MCU is operating with 180MHz. We are using an older version of freertos and LWIP (not taken from the SDK). The SPI interrupt has the second highest interrupt priority and SPI DMA has the highest interrupt priority. The wwd task has the highest priority as a task. There should be no long interrupt processing during the test.
We have experienced rare cases where WLAN communication stops when continuously under heavy load.
In some cases the driver thread stalls in the line "result = host_rtos_get_semaphore( &wwd_transceive_semaphore, (uint32_t) WWD_THREAD_POLL_TIMEOUT, WICED_FALSE );" of wwd_thread_func(). Interrupt line can be high or low in this case.
In other cases the driver reported " Received a packet with a frametag which is wrong" or "gSPI underflow - packet size will be wrong".
After a modification to wwd_thread's wwd_sdpcm_process_rx_packet() function which ensures the driver never runs out of RX buffers the problem occures less frequently (after 8 - 70 hours). We now simply drop data for network stack if too many packets are queued.
Another test case that sends and receives ethernet frame without use of a network stack showed that the driver runs into errors after 3 to 10 minutes of operation when RX buffers are not freed.
Is there any specification for how long RX buffers might be unavailable without interfering with operation?
Are there any known issues when running out of RX buffers?
For the cases in which wwd_thread stops in the line "result = host_rtos_get_semaphore( &wwd_transceive_semaphore, (uint32_t) WWD_THREAD_POLL_TIMEOUT, WICED_FALSE );" of wwd_thread_func() the comment for the functions wwd_thread_func() indicates that interrupts could be missed.
> * It simply calls @ref wwd_thread_poll_all to send/receive all waiting packets, then goes
> * to sleep. The sleep has a 100ms timeout, causing the send/receive queues to be
> * checked 10 times per second in case an interrupt is missed.
In SDK 3.3.1 the timeout became override able:
#define WWD_THREAD_POLL_TIMEOUT (NEVER_TIMEOUT)
In some of the error cases we saw the interrupt line was still high when the bus was disabled and therefore an edge interrupt was never triggered again.
In the other code path the 100ms timeout should prevent the problem.
Is there a known problem with missed interrupts in the path where the bus is disabled?