Wi-Fi Combo Forum Discussions

Hi,

We are developing firmware for Adafruit Wiced Feather https://www.adafruit.com/product/3056 to connect to AWS IOT. Everything works well, except when Identity is not used (private key & device certificate are not set) much like connecting to Server verification only. Wiced got hanged by ssl_write_certificate() by SSL binary Library probably writing to some NULL pointer. I know Identity should be set but we have no control over what user write, sdk should return an ERROR_TLS_ something instead.

Based on WICED 3.3.1, I'd like to make web server and make any devices accessible anywhere.

I saw serveral discussions like How to create a global HTTP server ? .

I tested appliance demo,

and found that no devices which has different gateway with WICED can not access WICED webpage.

My AP has 192.168.0.1 and WICED appliance is connected to my AP with 192.168.0.13.

My mobile phone can view button page when mobile phone is connected to my AP,

but it can not when it is connected to other AP.

which application is good for remote access ?

** I tried to make temp_control application, but found xively does not support personal account creation any more.

Thanks

EY An

Hi All,

I am currently working on BCM9WCD1EVAL1 board which has BCM943362WCD4 chip

my task is to take data on BCM9WCD1EVAL1 from other MC board through UART and put it to MQTT i.e publish whatever packet i receive on uart

i used inbuilt MQTT code separately it is working fine and also used UART inbuilt code it working but i am Little confused in UART communication problems i am facing given below:-

PS: when i connect BCM9WCD1EVAL1 to my PC i get COM28

1.what is the purpose of this line in uart.mk file "GLOBAL_DEFINES := WICED_DISABLE_STDIO"

2.if i club two in built codes uart.c and mqtt.c i can not able to see debug messages of mqtt.c on COM28

   i have to remove/comment "GLOBAL_DEFINES := WICED_DISABLE_STDIO"

   once i remove/comment messages came but uart functionality not working

   mqtt.c uses "WPRINT_APP_INFO"

   what may be the issue ?

3.what API should be used to receive from UART and take into buffer and whole string send it to mqtt plublish mssg

4.can you explain the functionalities of below:-

"wiced_uart_receive_bytes( STDIO_UART, &c, &expected_data_size, WICED_NEVER_TIMEOUT )"

wiced_uart_transmit_bytes( STDIO_UART, TEST_STR, sizeof( TEST_STR ) - 1 )

5.which GPIO Header pins of  BCM9WCD1EVAL1 are for UART and which api we should use to print the debug messages?

6.how to use UART interrupts?

7.can in mqtt.c by just putting IP address of Ubuntu instance which running on amazon cloud will work? Ubuntu instance also running mqtt broker at aws

Turning to the community and cypherbridge​ for insight on yet another hard fault -- forum searches reveal no existing information on this topic.

We've observed a handful of hard-to-pinpoint hard faults, and pieced together some data from stack dumps.

Our faults seem to be coming from a memcpy call within tls_get_next_record

Since the source is not available, we can only work with the assembly. The link register and program counter points these instructions at the time of fault

tls_get_next_record: ... +152 bl 0x804e580 <memcpy> ldrh.w r9, [sp, #12] (LR) memcpy: ... +266 ldrb.w r4, [r1], #1 (PC) cmp r1, r2 strb.w r4, [r3, #1]! bne.n 0x804e68a <memcpy+266>

For all the occurrences, the devices were on WICED 3.1.2, with no particular timing pattern, or any pattern for that matter. We've recently migrated to WICED 3.5.2, and haven't observed anything since, but it's too early to draw any conclusions. Is this a known issue, and is anybody else experiencing similar faults?

The SDK changelogs does mention a couple of TLS fixes and improvements, but nothing that addresses this issue in particular.

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>echo Transmit 802.11n : Start
Transmit 802.11n : Start

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>set comport=4

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>set target=4343WA1

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>rem set target=43362A2

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>rem set target=4390A1

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>rem set target=43341B0

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>..\wl4343WA1 --serial 4 down

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>rem ..\wl4343WA1 --serial 4 country ALL

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>..\wl4343WA1 --serial 4 channel 1

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>..\wl4343WA1 --serial 4 mpc 0

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>..\wl4343WA1 --serial 4 up

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>..\wl4343WA1 --serial 4 nrate -r 54

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>..\wl4343WA1 --serial 4 pkteng_start 00:11:22:33:44:55 tx 40 1000 0
set_info_fe: remote cdc header return error code (-23)
..\wl4343WA1: error -23

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>..\wl4343WA1 --serial 4 txpwr1 -1

..\WICED\WICED-SDK-3.5.2\WICED-SDK\libraries\test\wl_tool\scripts>rem ..\wl4343WA1 --serial 4 phy_forcecal 1

How do I do here ?

Hello,

I'm trying to get the Bluetooth working on a my board but somehow I very often get the error:

GKI_exception 65524 getbuf: out of buffers

GKI_exception(): Task State Table

My pools are the following:

64 * 4

360 * 100

360 * 100

600 * 1

I tried to see what was happening by launching a periodic task that prints the state of the buffers using the GKI_* routines and it turns out that sometimes the buffers get filled in very quickly, in less than a second I get the two 360 buffers full. Why that ?

I can't really find a pattern for the behaviour, it happens when I launch a scan or when I try to discover the services of a connected device.

What are the recommendations for the pools sizes ? I don't find any documentation.

Thank you.

Arthur.