- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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.
Solved! Go to Solution.
- Labels:
-
Interrupts
-
SDK 3.x
-
SPI
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are investigating the issue, our internal reference CSP case ID is 973219
Best Regards,
Johan Jeppsson
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.