Wi-Fi Combo Forum Discussions
In bcm43455 FW, I would like to disable Adaptivity function.
Because Adaptivity function is required for EN300-328 in EU, but not requried for US.
So, for US model I would like to disable adaptivity function in bcm43455 FW.
Could someone please instruc how to disable adaptivity??
Thank you
Show LessAll of a sudden, I can not set regular breakpoints. Instead WICED is setting these "hit points". I see the little dot next to the instruction. When the program encounters one, it reports that it hit that point in the console but it doesn't stop so that I can look around or single step. How do I get WICED back to setting traditional breakpoints the way it used to work?
Show LessFollowing websocket library bugs that I found, I keep finding more bugs/omissions in other parts of the SDK.
HTTP server library
- wiced_get_http_packet_state_and_socket_context doesn't work as intended. It uses wiced_http_message_context_t* socket_http_context as an output argument, which obviously never works, because it just assigns this pointer (it should be a pointer to a pointer), so the context is never actually restored, and messages arriving when packet state is HTTP_DATA_ONLY_FRAME_STATE will always fail. I guess it was tested with very basic requests, so this code path was never exercised, it works by coincidence.
- wiced_http_server_set_http_message_body_type_for_socket and wiced_reset_current_message_body_context_for_socket have conflicting logic: "Set" function will try to get a free context slot using socket_http_message_context_counter as index, and "reset" will loop through the list, nullify found element, but then simply decrement socket_http_message_context_counter, thus erasing a valid element instead of the one it just nullified. I suppose it also works by coincidence, because there are no more than 1 concurrent connection at a time, so it also works by coincidence.
- server_event_queue is a global object, so it's not possible to start more than one HTTP(S) server (for example port 80 and port 443). It stems from the issue that it's not possible to pass custom context to WICED TCP callbacks the library is built on, so it relies on a global variable.
TCP server library
- Not so much of a bug, but undocumented "feature": WICED_MAXIMUM_NUMBER_OF_SERVER_SOCKETS is set to WICED_MAXIMUM_NUMBER_OF_SOCKETS_WITH_CALLBACKS, which makes creating two TCP servers fail mysteriously.
DCT writing
- Pretty glaring bug in wiced_dct_write_wifi_config_section that writes DCT_SECURITY_SECTION instead of DCT_WIFI_CONFIG_SECTION. The function is deprecated, but should not be a reason for it to be unusable.
Missing factory reset DCT support
- factory_reset_dct target in the Makefile clearly refers to wiced_factory_reset.mk file that's missing from the SDK.
Can anyone from Broadcom comment on these, and whether an updated SDK will be available soon, so I don't have to maintain patches for these bugs?
Show LessI know this is probably the wrong place to ask, but...
Has anyone else seen a problem with the Avnet BCM94343W Evaluation board and "download_apps".
Specifically this:
resources | 55188 | 0 |
Ring_Buffer | 92 | 0 |
SPI_Flash_Library_BCM94343W_AVN | 512 | 0 |
Startup Stack & Link Script fill | 49 | 18 |
Supplicant - BESL | 37232 | 536 |
ThreadX | 8588 | 396 |
TLV | 200 | 0 |
WICED | 4739 | 968 |
Wiced_RO_FS | 568 | 0 |
WWD | 15973 | 3048 |
----------------------------------+---------+---------|
TOTAL (bytes) | 300860 | 57936 |
----------------------------------|---------|---------|
Downloading Bootloader ...
make: *** [main_app] Segmentation fault: 11
No changes detected
Download complete
The exact place of the failure is in the execution of:
./tools/OpenOCD/OSX/openocd-all-brcm-libftdi
in the makefile "standard_platform_targets.mk", and in the "download_bootloader".
I have validated that every file required for the command is present. I have not tried to run the command from a command line yet, but was trying to short circuit all the debugging time I need to spend to find the problem. Strangely, I have seen it complete 3 or 4 times for unknown reasons. I have tested this on Windows and it appears to work perfectly leading me to believe that it might be a race condition somewhere in the boot loader code. I've searched for community and located some old tricks but none really apply to this problem.
Show LessHi, I am using BCM4330 combo-chip for a WiFi enabled device. The device has issues with running WMM related test cases with 802.11n test plan. I wonder if somebody can provide me an ASD for BCM4330, or give me some ideas about why WMM test cases are failed with traffic differentiation on receive direction. There is no issue with transmit directed test cases.
Show LessDo we have the possibility to have some help from Broadcom to integrate the bmc4330 or bmc4329 to the Wiced SDK?
Can we have access to FW associated to these chips?
Hugo
Show LessHi Sir,
Our product can't pass wifi adaptivity test, we verify again by BCM943341WCD1 EVB but fail, too.
Please refer following test method and advise, thanks.
[Safety]
2.4GHz EN300328 Adaptivity v1.91
5GHz EN301893 Adaptivity v1.81
[DUT]
BCM943341WCD1
[SDK]
SDK 3.5.2
SDK 3.7.0
[Test sample code]
Snip.apsta
void application_start(void) { uint16_t max_sockets = 10; /* Initialise the device */ wiced_init(); /* Bring up the STA (client) interface ------------------------------------------------------- */ wiced_network_up(WICED_STA_INTERFACE, WICED_USE_EXTERNAL_DHCP_SERVER, NULL); /* The ping target is the gateway that the STA is connected to*/ wiced_ip_get_gateway_address( WICED_STA_INTERFACE, &ping_target_ip ); } |
[wifi firmware]
wl0: Nov 25 2015 14:01:39 version 6.49.2 (r602357) FWID 01-1302682f
[Test result] - fail
5Ghz
2.4Ghz
[NVRAM modified range]
edonthd= -65 ~75
edoffthd= -71 ~81
Show Lesswe try to porting http_client to customer cloud API.
But we try the same url to get a 4MB file with wiced_http_get and wiced_https_get.
\wiced 3.7.0\snip\http_client.c
for example,
#define url-data "/201307/09grZeMhnj4ojGhc0O5YFIhfQXaXGJaDaVV_uMNbOtbTgDqSWg==?play_mode=openapi&__gda__=1469510554_a5e16545f9882ab0d5015b4888dbc31f"
tx_data[0]=0x00;//clear a string
sprintf(tx_data,"GET %s HTTP/1.1\r\n",url_data);
strcat(tx_data,"Host: fs-sq-1.kfs.io\r\n");
strcat(tx_data,"Accept: */*\r\n");
strcat(tx_data,"\r\n");
result = wiced_http_get( &ip_address, tx_data, buffer, BUFFER_LENGTH);//result will return WICED_OK
result = wiced_https_get( &ip_address, tx_data, buffer, BUFFER_LENGTH, NULL );//result will return ERROR_INVALID_MAC(5006)
After check 5006 error from \WICED-SDK-3.7.0\WICED\security\BESL\include\besl_structures.h
But we don't know hot to fix this problem in https_get because we use the same WIFI modue with the same MAC address.
we just use different api (wiced_http_get,wiced_https_get) to get file.
Any one see the same problem on "snip\http_client" wiced_https_get?
Show LessHello,
I'm working on an application with WICED Wi-Fi SDK 3.3.1, that requires both Wi-Fi and BLE Server. Furthermore, I need to set a different Bluetooth MAC address for all the products. I noticed there is a way to do it in WICED Smart SDK, but I didn't find any equivalent in the Wi-Fi SDK.
Is there any way to change the Bluetooth MAC address, for example at the flash time as it's done in WICED Smart ?
Thanks for your support !
SDK version : WICED 3.3.1
Microcontroller : STM32F415
Wi-Fi/BT chip : Murata Type 1BW (based on BCM43341)
Show LessThere is a bug in SDK versions prior to 3.5.2 (included), where the device fails to pair with a peer after the stock API "wiced_bt_set_local_bdaddr" is called.
BCM4343w modules have the same Bluetooth MAC address
Re: Changing Bluetooth MAC address with Wi-Fi SDK 3.3.1
And here are some workarounds for this issue. (without using the stock API at all)
Purpose:
1. assign BLE MAC address at compile time
2. change BLE MAC address at run time
The default BLE MAC used at run time is stored in APP_CODE binary.
It actually comes from libraries/drivers/bluetooth/firmware/<MODEL>/<FREQUENCY>/bt_firmware_image.c
Where <MODEL> and <FREQUENCY> can be found in platform definitions.
For example, in my case <MODEL>=43438A1, <FREQUENCY>=37_4MHz.
Find the stock BLE MAC address in the file and modify as you want. (the byte order may be different from your convention)
const uint8_t brcm_patchram_buf[] =
{
0x4C,0xFC,0x46,0x00,0x17,0x21,0x00,0x42,0x52,0x43,0x4D,0x63,0x66,0x67,0x53,0x00,
0x00,0x00,0x00,0x32,0x00,0x00,0x00,0x01,0x01,0x04,0x18,0x92,0x00,0x00,0x00,0x03,
// 0x06,0xAC,0x1F,0x12,0xA1,0x43,0x43,0x00,0x01,0x1C,0x42,0x17,0x21,0x00,0x00,0x00,
0x06,
#ifdef REVERSED_PRODUCT_MAC_ADDRESS_BYTES
REVERSED_PRODUCT_MAC_ADDRESS_BYTES,
#else
0xAC,0x1F,0x12,0xA1,0x43,0x43,
#endif
0x00,0x01,0x1C,0x42,0x17,0x21,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0xFE,0x00,0x00,0x4C,0xFC,0xFF,0x42,0x17,0x21,0x00,
0x42,0x52,0x43,0x4D,0x63,0x66,0x67,0x44,0x00,0x00,0x00,0x00,0xF1,0x39,0x00,0x00,
With the above modification BLE MAC address should be assigned at compile time.
To change BLE MAC address at run time we need to modify the content in APP_CODE (MCU internal flash) before BLE is brought up.
I do this right after "wiced_init" is called.
#include "waf_platform.h"
extern const uint8_t brcm_patchram_buf[];
platform_write_flash_chunk((uint32_t)&brcm_patchram_buf[OFFSET_TO_MAC], new_mac, 6);
I'm still testing if this cause any further problems, but so far so good.
I'll be happy if this helps anyone, and I'll be appreciated if any bug/fix is provided as feedback.
Show Less