Wi-Fi Combo Forum Discussions

Hello,

Where can I buy BCM943341 module alone? Is there any alternate modules available? I found one from Azurwave but that module is lack of JTAG signals. TDI and TSRST signals are missing (used for LTE co-existance, hence not available). I think I can't hook this module, without all JTAG signals, to PC and use Broadcom's SDK and IDE for the development and debugging. Any suggestions are welcome.

Basavaraj

Hi all,

I've got a custom board with the Auth chip, which is largely based on the eval board, with the auth chip connected correctly. I am able use WAC to configure the board with WiFi access. I've created one simple "outlet" accessory, with one accessory information service, and one outlet service and two characteristics (on and outlet-in-use). I am able to call wiced_homekit_start, and it returns the success code.

Now when I use either HAT or the demo app from Apple, I am able to see this accessory. A bonjour browser app also verifies that the _hap._tcp service is being advertised. I have also been able to run the identify routine, but this didn't work out of the box. I had to play with the timings of other initializations I was performing in my accessory, and it somehow started working.

At this point, I expect I should be able to pair with the device. However, I'm unable to do this either with the HMCatalog demo iOS app, or via HAT. I do get prompted to enter the code, and I'm using the wiced_configure_accessory_password_for_device_with_no_display() method.

With HAT, I get a the following message, which is the only  information I'm able to obtain to debug this problem:

Message: __46-[HAPAccessoryServerIP _pairSetupTryPassword:]_block_invoke ### Unable to send request to try password during Pair Setup, received response object: (null), MIME type: Unknown, error: Error Domain=HMErrorDomain Code=59 "Failed with OSStatus code 200500 (Internal Server Error)" UserInfo=0x60000086b240 {NSLocalizedDescription=Failed with OSStatus code 200500 (Internal Server Error)}

Otherwise, the whole HomeKit module is a black box. I'm using OS X with 3.1.2 for firmware development. Most of build and code downloading for HomeKit seems to work fine, I just use the make scripts on the command line (no IDE). I have USE_MFI=1. I assume GEDDAY is being used. When I try USE_BONJOUR=1 in addition, I think there are memory issues, because the application hangs, so I'm not using the Bonjour flag.

In SDK 3.1.1, I used to get some debug outputs during the WAC process. With 3.1.2, there are no debug outputs. I have no idea where to start debugging. Is there any WICED HomeKit documentation other than that is in the comments of the sample HomeKit app? Any help is greatly appreciated.

Can anyone tell how to access the SPI in BCM943362WCD4

In the sample example in SDK3.1.2 it is saying that platform is not supported...

Can anyone explain how to get data from spi ?

I have downloaded this file from WICED SDK site: sdk312_1_1_4390_antenna_diversity.7z When I unzipped it, I could not open it. Please let me know what's inside and what program is needed to open it. THX.

Dear all,

i have a murata module sn8000, with his external pinout directly connected to bcm43362. Using brcmfmac linux driver, on kernel 3.10 (and some adaption to the brcmfmac driver since this chip starts to be supported on kernel 3.14), i could have the module correctly SDIO (4-bit mode) probed and working. Mainly after some changes to the drive-strength controlling processor pin config, the module started to get successfully probed.

The sequence of the init operations seems to be the following:

a. linux generic SDIO driver probe the bus

b. once chip is detected, brcmfmac driver specific probe is used

c. brcmfmac initialize the chip and upload the firmware

d. userspace setup

e. wlan0 up

Now, after some days, the module started to fail on SDIO probe (step "a", still no brcmfmac driver involved here),  and then, after some additional retries, the module is no more successfully probed.

So issue is still at SDIO probing stage (linux throw SDIO error -110, timeout). I would appreciate any information useful to debug and understand why  the probe fails, especially:

- any useful information on the driver strength or configuration of the pins

- what can block bcm43362 in a way that it doesn't reply to probing

I have oscilloscope available, i see SDIO clk and commands happening, but no replies or state changes in the 4 data lines.

Every help is very appreciated

angelo

Hi,

One of our customer is facing problem While  creating their own make file. Customer is using SDK3.1.2 using SSB-WM-N01 (based on BCM43362) Evaluation Board.

I am attaching Queries and Procedure followed as per SDK Quick Starter Guide where your support is needed.

Thank's

Jagadish.H

I have built and tested the OTA using the ISM43362_M3G_L44 using the instructions in the the WICED 3.1.2 notes. The downloaded application works and I am able to upload the snip-scan stripped.elf image and control transfers successfully to this program and then runs. Output below

------------------------------------------

Writing chunk 291 of size 544 from offset 296960

Uploaded file size = 297504

Restarting..

Starting WICED v3.1.2

Platform ISM43362_M3G_L44 initialised

Started ThreadX v5.6

Initialising NetX_Duo v5.7_sp1

Creating Packet pools

WWD SDIO interface initialised

WLAN MAC Address : C4:7F:51:01:1B:2F

WLAN Firmware    : wl0: Nov  7 2014 16:03:45 version 5.90.230.12 FWID 01-8da0c768

Waiting for scan results...

  # Type  BSSID             RSSI  Rate Chan  Security    SSID

----------------------------------------------------------------------------------------------

  0 Infra 08:86:3B:71:A5:C4  -93 144.4    1  WPA2 AES    belkin.5c4                      

etc.....

---------------------------------------------

When I download my working App (.stripped.elf) the app does not start but restarts the OTA upgrade process.

------------------------------------------------

Writing chunk 835 of size 1024 from offset 854016

Writing chunk 836 of size 340 from offset 855040

Uploaded file size = 855380

Restarting..

Starting WICED v3.1.2

Platform ISM43362_M3G_L44 initialised

Started ThreadX v5.6

Initialising NetX_Duo v5.7_sp1

Creating Packet pools

WWD SDIO interface initialised

WLAN MAC Address : C4:7F:51:01:1B:2F

WLAN Firmware    : wl0: Nov  7 2014 16:03:45 version 5.90.230.12 FWID 01-ada8e728

Hi, I'm the Production App (ota_fr).

Watch while I toggle some LEDs ...

Time for an upgrade. OTA upgrade starting ...

Setting IPv6 link-local address

IPv4 network ready IP: 192.168.10.1

-----------------------------------------------------------

Could you give me some indication regarding what could be going wrong here.

The end goal is to trigger the OTA process from my app and have that provide the ability to upgrade the app via OTA

Assistance would be appreciated. What is the total size of the App. I see the end of FLASH in the map file @  0x080d1640 so seem we still have some space....

Thanks

Greg

Hello,

I'm trying to setup some higher-frequency data capture (~8ms period) on a STM32F2XX-based WICED module.  This seems to work fine 99.5% of the time, but on average I seem to be missing 0.5% of the interrupts I expect to be processing.  I've setup a scope to monitor this and it looks like most if not all of the losses come from a spurious event that seems to happen every 5-30 seconds.  This event lasts either ~100ms or ~240ms and prevents the interrupt request from being processed.  Interestingly, when the event is ~100ms in length, the ISR appears to run (my trace GPIO gets asserted), but the event being posted to a high-priority worker thread to do the processing is not run (GPIO not released for the full ~100ms).  When the event is ~240ms in length, the ISR doesn't appear to run at all (GPIO never asserted).

A bit more detail on the setup:  This is using ThreadX/NetX-Duo.  I've created a high-priority worker thread for doing the data collection work (runs at priority-level 0) and dropped the WWD thread and system monitor threads to priority level 1.  I've also applied the ThreadX patch that was posted in a blog entry to allow preemption of lower priority threads.

Any hints guidance as to what might be causing this would be greatly appreciated!  Cheers!