Wi-Fi Combo Forum Discussions
I want to write some user information in the OTP memory at manufacturing. There are about 40 bytes is not used in our 43362's OTP memory. I want to use 32 bytes to save some user information. From page 18 in the "OTP Programming Procedure", the CIS format is <80> <length> <tag> <value>. So I want to add a tag to save this 32 bytes: 80 32 <tag> <32 bytes data>. Can you tell me which tag I can use?
Another question: I can use IOCTL "cisdump" to dump the OTP by the manufacture firmware, but this command is unsupported in the normal firmware. Can you help to add a command to dump the OTP in the normal firmware?
Thanks!
Show LessHi, all:
Modified the sample code
Wiced-SDK-2.4.0-RC1\WICED-SDK\Apps\snip\udp_receive
Wiced-SDK-2.4.0-RC1\WICED-SDK\Apps\snip\udp_transmit
After test, the throughput is very small and hard to meet the 802.11a (54Mb/s) or 802.11n(150Mb/s).
Does anyone have experice about throughput on this chip?
Thank you
Show LessHi,
I am very new to Wiced development and just now installed wiced SDK. However I am getting this below error and could not let me build target described in quick start guide section 4. Can anyone please guide me through this?
**** Build of configuration Default for project WICED-SDK-2.4.1 ****
make snip.scan-BCM943362WCD4-debug download run
wiced_toolchain_common.mk:187: *** incorrect 'make' used (/Applications/Xcode.app/Contents/Developer/usr/bin/make) - please use: (Windows) .\make.exe <target_string> (OS X, Linux) ./make <target_string>. Stop.
Thanks,
Best Regards,
Dipen Patel
Show LessDear,
I am testing the OTA Update using the program of snip.ota_fr in WICED SDK v2.4.1.
The comments in this ota_fr.c told me that the first step is running this command as follow:
snip.ota_fr-BCM943362WCD4 OTA=waf.ota_upgrade SFLASH=app-dct-ota-download
The platform I used is BCM9WCDUSI09, so I changed the command as:
snip.ota_fr-BCM9WCDUSI09 OTA=waf.ota_upgrade SFLASH=app-dct-ota-download
But it failed. Is the RAM too small?
The Log is in the attachment.
Could anyone help me to find the problem? Thanks.
BTW, the SPI Flash in my board is 4MByte.
According to the Platform pin map in platform.h for the BCM943362WCD4, WICED_GPIO_2 or MICRO_ADC_IN1 only has GPIO and TIM2_CH2 and TIM5_CH2 alternate functions. However the input calls it ADC. Can it actually be confirgured as an ADC pin ?
Show LessHi all,
I've two problems.
I've implementing some code between LwIP and WWD. My code contains one thread with queue (I use own queue implementation).
I found point of integration of my code between LwIP and WWD. To receive data from LwIP I've used own function instead of wiced_network_send_ethernet_data() function and in my code I call wiced_network_send_ethernet_data() function to send data to WWD. I receive data from WWD in function host_network_process_raw_packet().
So, my code receives data from WWD, then does some modification in own thread and then sends it to LwIP.
Also I've enabled monitor mode and changed in function wiced_wifi_prepare_join parameter for ioctl WLC_SET_INFRA to zero to enable Ad-Hoc mode.
First my problem is about function wiced_network_send_ethernet_data().
If I allocate own packet by function host_buffer_get and function wiced_network_send_ethernet_data() often fails inside itself in piece code:
/* Add link space at front of packet */
result = host_buffer_add_remove_at_front( &buffer, (int32_t) -WICED_LINK_OVERHEAD_BELOW_ETHERNET_FRAME );
if ( result != WICED_SUCCESS )
{
So, it means that function host_buffer_add_remove_at_front can't allocate additional space before buffer.
I found 2 workarounds here. First is to allocate new temp buffer by malloc, then copy current to buffer to it, and then create new buffer by function host_buffer_get with enough space.
Second workaround is to allocate huge buffer in my code and there use function host_buffer_add_remove_at_front to decrease size. It allows to allocate additional spaces later in function wiced_network_send_ethernet_data().
But it looks strage, what do you think?
My second problem is in WWD driver. When all this stuf is working (LwIP <-> My code <-> WWD driver + monitor mode + ad-hoc), WWD driver stalls after several seconds. So I'm able to send several packets between modules but after several second they don't want to send or receive any packets.
I see in debugger that wiced_thread_func (in file wwd_thread.c), where WWD shall send/receive packets, stalls in getting semaphore:
result = host_rtos_get_semaphore( &wiced_transceive_semaphore, (uint32_t) WICED_THREAD_POLL_TIMEOUT, WICED_FALSE );
Do anybody know what I did wrong in the code that could lead to this behaviour?
P.S.
My boards: SSB-WM-N01
SDK version: 2.4.1
Show LessHello,
I have a issue with the ca certificate verification on the WICED SDK 3.0.1 and 2.4.0 (both FreeRTOS + LwIP).
I have a server at HomeManager and I have the following CA certificate:
"-----BEGIN CERTIFICATE-----\n"\
"MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE\n"\
"ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5\n"\
"MB4XDTk4MDgyMjE2NDE1MVoXDTE4MDgyMjE2NDE1MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoT\n"\
"B0VxdWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCB\n"\
"nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPR\n"\
"fM6fBeC4AfBONOziipUEZKzxa1NfBbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+AcJkVV5MW\n"\
"8Q+XarfCaCMczE1ZMKxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kCAwEAAaOCAQkwggEFMHAG\n"\
"A1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UE\n"\
"CxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoG\n"\
"A1UdEAQTMBGBDzIwMTgwODIyMTY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvS\n"\
"spXXR9gjIBBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQFMAMB\n"\
"Af8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUAA4GBAFjOKer89961\n"\
"zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJXRmm/kEd5jhW6Y7qj/WsjTVbJmcVfewCHrPSqnI0kB\n"\
"BIZCe/zuf6IWUrVnZ9NA2zsmWLIodz2uFHdh1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee95\n"\
"70+sB3c4\n"\
"-----END CERTIFICATE-----\n";
On the WICED SDK 2.4.0 when I try to connect and verify the server's certificate the chip goes to hardware fault. I have managed to track the error to the file wiced_tls.c in function wiced_tcp_start_tls. When the board enters the do { ... } while(...) loop, it calls the function ssl_handshake_client_async 3 times and the tls_context->context.state goes from 1 to 2 and 3. After 3 it goes to hardware fault.
On the WICED SDK 3.0.1 when I try to connect I get an error (no hardware fault) but still it doesn't want to connect. The SSL certificate on that server is a wildcard, so it is issued for *.homemanager.tv. I have tried the following wiced_https_get commands and got the following errors:
result = wiced_https_get( &ip_address, SIMPLE_GET_REQUEST, buffer, BUFFER_LENGTH, "www.*.homemanager.tv" ); -> error 2
result = wiced_https_get( &ip_address, SIMPLE_GET_REQUEST, buffer, BUFFER_LENGTH, "*.homemanager.tv" ); -> error 65024
result = wiced_https_get( &ip_address, SIMPLE_GET_REQUEST, buffer, BUFFER_LENGTH, "www.homemanager.tv" ); -> error 2
result = wiced_https_get( &ip_address, SIMPLE_GET_REQUEST, buffer, BUFFER_LENGTH, "homemanager.tv" );-> error 65024
The certificate should be ok. It works fine under Linux where I call the SSL_get_verify_result from OpenSSL. I assume that the board has to do more or less the same thing as that OpenSSL function.
Any suggestions? I would prefer a fix for the 2.4.0 version because the end product is based on the USI09 chip.
Show Less