Wi-Fi Combo Forum Discussions

Hello all,

I am trying to create a DTLS client in order to comunicate with a remote DTLS server. I would like to use the WICED SDK with its BESL library but I cannot manage to get a DTLS handshake to work properly with the 5.0 SDK. I was using a former version of the BESL library with the 3.5.2 WICED SDK and the dtls handshake client function was working well whereas it does not with the new version.

Is this function still working well and if yes, does any example exist in order to get it work with this new BESL library ?

Thanks,

F. Piller

Has anybody had success installing the drivers that WICED Studio 5.0.0.33 provides for the UART and JTAG ports on WICED dev boards? I tried several times to install the drivers provided in %SDK%\WICED-Studio-5.0\Drivers\Windows, both through the Studio installer and manually by running the DPinst_x64.exe's in the two subdirectories. However, Device Manager continued to show the two devices presented by my BCM94343WWCD1 dev board in the "Other" category and indicate that no driver was installed. Finally, I tried downloading Studio 4.1.1.8 and ran the manual driver installers from there, and the UART and JTAG port enumerated properly. I'm running 64 bit Win 10 Pro, version 1703, build 15063.332.

Hello,

i have a question related with i2c slave mode.

when i checked wiced_i2c_init() i have seen that it prepares i2c as master but i want to use it as slave mode. is there any way for it or it is impossible to use as slave?

it is SDK:3.5.2

Best wishes

Hi,

I'm having trouble loading the WiFi firmware during wiced_init(). In WWD/internal/bus_protocols/wwd_bus_common.c,

result = host_platform_resource_size( resource, &size );
    if( result != WWD_SUCCESS )
    {
        WPRINT_WWD_ERROR(("Fatal error: download_resource doesn't exist\n"));
        goto exit;
    }
    if ( size <= 0 )
    {
        WPRINT_WWD_ERROR(("Fatal error: download_resource cannot load with invalid size\n"));
        result = WWD_BADARG;
        goto exit;
    }

size would come up to be 0 causing that "Fatal error: download_resource cannot load with invalid size\n".

Any idea why?

Hi,

I've found out that "download_apps" actually doesn't download the firmware to the SPI flash on the BCM4343W_AVN platform. Has anyone experienced anything like this?

Here's my OpenOCD output:

Open On-Chip Debugger 0.10.0-dev-00224-g217aaab-dirty (2016-09-08-15:37)

Licensed under GNU GPL v2

For bug reports, read

    http://openocd.org/doc/doxygen/bugs.html

Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter speed: 2000 kHz

adapter_nsrst_delay: 100

none separate

post_init_43909_setup

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

Info : clock speed 1800 kHz

Info : STLINK v2 JTAG v27 API v2 SWIM v6 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 3.208372

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

26820 bytes written at address 0x20000000

downloaded 26820 bytes in 0.301316s (86.923 KiB/s)

entry_address= 536888685

stack_address= 536907212

buffer_size= 16384

pc (/32): 0x2000456D

Total write size is 383156

writing 16384 bytes at 4096

stm32f4x.cpu: target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x81000000 pc: 0x20005fde msp: 0x20008d7c

loadimage address 536870940 foffset 0 16384

16384 bytes written at address 0x2000001c

downloaded 16384 bytes in 0.178440s (89.666 KiB/s)

stm32f4x.cpu: target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x21000000 pc: 0x20006374 msp: 0x20008c34

stm32f4x.cpu: target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x61000000 pc: 0x200052c4 msp: 0x20008c14

stm32f4x.cpu: target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x41000000 pc: 0x20005540 msp: 0x20008c24

stm32f4x.cpu: target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x61000000 pc: 0x20004a68 msp: 0x20008cf4

stm32f4x.cpu: target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x2100dc00 pc: 0x20005244 msp: 0x20008c1c

stm32f4x.cpu: target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x21000000 pc: 0x200063a2 msp: 0x20008c6c

stm32f4x.cpu: target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x61000000 pc: 0x20004dd2 msp: 0x20008d0c

stm32f4x.cpu: target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x21000000 pc: 0x200063d4 msp: 0x20008d74

****************** Result: Verify after write failed

stm32f4x.cpu: target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x41000000 pc: 0x200063b4 msp: 0x20008d74

===== arm v7m registers

(0) r0 (/32): 0x40000800

(1) r1 (/32): 0x20008D78

(2) r2 (/32): 0x40010000

(3) r3 (/32): 0x00000004

(4) r4 (/32): 0x2000000C

(5) r5 (/32): 0x2000000C

(6) r6 (/32): 0x0000100A

(7) r7 (/32): 0x200068C4

(8) r8 (/32): 0x00000000

(9) r9 (/32): 0x0000100A

(10) r10 (/32): 0x00000000

(11) r11 (/32): 0x2000401C

(12) r12 (/32): 0x00000000

(13) sp (/32): 0x20008D74

(14) lr (/32): 0x200059C7

(15) pc (/32): 0x200063B4

(16) xPSR (/32): 0x41000000

(17) msp (/32): 0x20008D74

(18) psp (/32): 0x00000000

(19) primask (/1): 0x00

(20) basepri (/8): 0x00

(21) faultmask (/1): 0x00

(22) control (/2): 0x00

(23) d0 (/64): 0x0000000000000000

(24) d1 (/64): 0x0000000000000000

(25) d2 (/64): 0x0000000000000000

(26) d3 (/64): 0x0000000000000000

(27) d4 (/64): 0x0000000000000000

(28) d5 (/64): 0x0000000000000000

(29) d6 (/64): 0x0000000000000000

(30) d7 (/64): 0x0000000000000000

(31) d8 (/64): 0x0000000000000000

(32) d9 (/64): 0x0000000000000000

(33) d10 (/64): 0x0000000000000000

(34) d11 (/64): 0x0000000000000000

(35) d12 (/64): 0x0000000000000000

(36) d13 (/64): 0x0000000000000000

(37) d14 (/64): 0x0000000000000000

(38) d15 (/64): 0x0000000000000000

(39) fpscr (/32): 0x00000000

===== Cortex-M DWT registers

(40) dwt_ctrl (/32)

(41) dwt_cyccnt (/32)

(42) dwt_0_comp (/32)

(43) dwt_0_mask (/4)

(44) dwt_0_function (/32)

(45) dwt_1_comp (/32)

(46) dwt_1_mask (/4)

(47) dwt_1_function (/32)

(48) dwt_2_comp (/32)

(49) dwt_2_mask (/4)

(50) dwt_2_function (/32)

(51) dwt_3_comp (/32)

(52) dwt_3_mask (/4)

(53) dwt_3_function (/32)

I'm having trouble with the BCM94343W_AVN platform (4343W with STM32F411 MCU) and SDK 4.0.1. The wiced_init() would hang and fail because of platform_filesystem_init().

And more specifically, through the help of GDB, I find that result = wicedfs_init( 0, read_callback, &resource_fs_handle, &wicedfs_sflash_handle ); would return -1.

Inside wicedfs_init, it fails here:

bytes_read = read_func( user_param, &fs_header, (wicedfs_usize_t) sizeof(fs_header), base );

    if ( bytes_read != sizeof(fs_header) )

    {

        return -1;

    }

Does anyone have any idea of what could go wrong? Other examples can compile just fine. And I don't have code executed before wiced_init().