ioctl timeout due to missing interrupt

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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.

During initialization we experience reproducable timeouts of ioctl commands issued after the firmware download.

The wwd_bus_init() function completes successfull but the further ioctl interactions of wwd_management_wifi_on() fail on different calls (timing dependant). An oscziloscope trace shows that after a couple of commands the SN8000 does not singal a SPI IRQ anymore.

The initialization function returns "Could not set AMPDU parameters" with an errorcode 2 (timeout).

The error does not occure at every start and if initialization completes successfully the SPI communication seems to work allowing conifguration of the WLAN module and exchange of data. Modifications of the timing make the error appear on different ioctl calls within wwd_management_wifi_on(). The traces show half completed communication sequences with missing SPI IRQ after a couple of successfull communication sequences with interrupts from SN8000.

If we continously using IOCTLs (by calling wwd_wifi_get_rate() in a loop) after initialization the WLAN module stops responding after some retries. If we delay the first call to wwd_wifi_get_rate() after the initialization (wwd_init()) the error occures faster! If we continue to use the 1ms delay for every SPI transaction even after intialization the IOCTL does not fail.

Some other users seem to have similar problems, but we have found no solution on the forum:

Re: set country code timeout

For now we added a delay of 1 ms for the first couple of SPI transfers which resolved the problem. However to gurantee a safe and stable operation we would really like to understand the cause of this behaviour.

We tried to rule out hardware based SPI problems.

We performed some tests driectly inside the wwd_bus_init function after reading the reset where the comment "/* Check feedbead can be read - i.e. the device is alive */" is located.

The Test–Read only register of the gSPI Interface returns always the same vaule when read in a loop.

Continously writing the Test-R/W register of the gSPI Interface with increasing numbers always returned the written number when reading.

Additionally we have sent 1200 byte UDP packets to an echo server and checked the returned packets for data inegrity using IP and UDP checksum. The test never returned an invalid checksum.

0 Likes
1 Solution
Anonymous
Not applicable

As we concluded in direct conversations, the SDIO interface is a better option. SPI generally takes some tuning and we are now only recommending SPI when the MCU doesn't have SDIO.

View solution in original post

0 Likes
5 Replies
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

We were able to reproduce the problem on the Broadcom BCM943362WCD4 evaluation board.

The problem appears later and less likely than on our own PCB.

It seems very timing dependant. Slight modifications to the code make the problem appear much more likely or make it disappear completely.

To reproduce the issue we used the unmodified WICED-SDK-3.1.2 with the patch for LwIP (https://community.broadcom.com/thread/3327).

We replaced the file scan.c in WICED-SDK-3.1.2\apps\snip\scan with the attached content.

We compiled and downloaded the application to the BCM943362WCD4 (Rev 1, S/N 1828382) Evaluation Board using the following command:

make snip.scan-BCM943362WCD4-FreeRTOS-LwIP-SPI download run

The test generated the following output:

Starting WICED v3.1.2

Platform BCM943362WCD4 initialised

Started FreeRTOS v7.5.2

Initialising LwIP v1.4.0.rc1

WWD SPI interface initialised

WLAN MAC Address : 44:39:C4:31:79:47

WLAN Firmware    : wl0: Nov  7 2014 16:03:45 version 5.90.230.12 FWID 01-d0942660

IOCTL failed after 17319 iterations

IOCTL failed after 17319 iterations

IOCTL failed after 0 iterations

IOCTL failed after 48589 iterations

IOCTL failed after 0 iterations

IOCTL failed after 9233 iterations

IOCTL failed after 0 iterations

IOCTL failed after 11622 iterations

IOCTL failed after 0 iterations

IOCTL failed after 51425 iterations

IOCTL failed after 0 iterations

IOCTL failed after 31134 iterations

IOCTL failed after 0 iterations

IOCTL failed after 8354 iterations

IOCTL failed after 0 iterations

IOCTL failed after 23236 iterations

IOCTL failed after 0 iterations

IOCTL failed after 13259 iterations

IOCTL failed after 0 iterations

IOCTL failed after 16252 iterations

IOCTL failed after 0 iterations

...

IOCTL failed after 6083 iterations

IOCTL failed after 0 iterations

IOCTL failed after 0 iterations

IOCTL failed after 0 iterations

IOCTL failed after 0 iterations

....

Despite the delay before every retry sometimes multiple attempts to exchange the IOCTL fail.

0 Likes
Anonymous
Not applicable

We are investigating the issue, our internal reference CSP case ID is 973219

Best Regards,

Johan Jeppsson

0 Likes

Hi,

Supplied file is tested with a clean version of SDK-3.1.2 and later versions of SDK and there were no error reported.

What are the changes made to SDK before testing the above file?

09:45:26.693: Starting WICED v3.1.2

09:45:26.693: Platform BCM943362WCD4 initialised

09:45:26.693: Started FreeRTOS v7.5.2

09:45:26.693: Initialising LwIP v1.4.0.rc1

09:45:26.708: WWD SPI interface initialised

09:45:27.192: WLAN MAC Address : 40:2C:F4:AF:32:C5

09:45:27.192: WLAN Firmware    : wl0: Nov  7 2014 16:03:45 version 5.90.230.12 FWID 01-7245cdba

09:45:27.207:

09:45:27.301:

09:45:27.301: Start IOCTL get rate test.

09:45:27.301:

09:56:25.192: Starting WICED v3.1.2               <- Manually reset after 11 minutes later

09:56:25.192: Platform BCM943362WCD4 initialised

09:56:25.192: Started FreeRTOS v7.5.2

09:56:25.192: Initialising LwIP v1.4.0.rc1

09:56:25.208: WWD SPI interface initialised

09:56:25.676: WLAN MAC Address : 40:2C:F4:AF:32:C5

09:56:25.676: WLAN Firmware    : wl0: Nov  7 2014 16:03:45 version 5.90.230.12 FWID 01-724dcc3e

09:56:25.676:

09:56:25.785:

09:56:25.785: Start IOCTL get rate test.

09:56:25.785:

Thanks,

Seyhan

0 Likes
Anonymous
Not applicable

Hi Seyhan,

No alternations were done to the SDK 3.1.2 apart from the ones documented above (replacing the scan.c file and adding LWIP patch). We are using a Revision 1 Broadcom Evaluation Board BCM943362WCD4. Tests were carried out compiling the firmware on the command line (not using the IDE). I compiled a non debug version using:

make snip.scan-BCM943362WCD4-FreeRTOS-LwIP-SPI download run

So far I reproduced the error only with these specific settings.

I just repeated the steps and the first error started showing up after about 11 seconds.

Johan Jeppsson wrote to me on 24th of September that he reproduced the error:

>I am now running the test and can confirm it also produces the same output/issue on my board. I am testing SDK3.3.1 right now.

As stated above the testcase the behaviour seems very timing dependant. Slight modifications to the code make the problem appear much more likely or make it disappear completely.

I see from the console output of your post that the testcase is slightly altered. The message "Start IOCTL get rate test." is not printed in the posted scan.c file.

Best regards,

  David

0 Likes
Anonymous
Not applicable

As we concluded in direct conversations, the SDIO interface is a better option. SPI generally takes some tuning and we are now only recommending SPI when the MCU doesn't have SDIO.

0 Likes