Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

The call path is:

wiced_init()

wiced_wlan_connectivity_init()

wwd_management_wifi_on()

wwd_management_wifi_platform_init()

     wwd_bus_init()

and it appears that the problem is occuring in wwd_bus_init()

and the return value if wiced_init() is 2 which is TIMEOUT which implies that some sort of handshake is not occurring properly between the STM32F411 and the 943362.

All the pins look correctly in     wifi_spi_pins     and none of that was changed.

I don't think the bootstrap pins are connected per a schematic and I tried various combinations of changing the existing

#define WICED_WIFI_USE_GPIO_FOR_BOOTSTRAP

to

#define WICED_WIFI_USE_GPIO_FOR_BOOTSTRAP_0

#define WICED_WIFI_USE_GPIO_FOR_BOOTSTRAP_1

with no good result.

The bootstrap pins are defined, but I think that's a legacy stamp copy as they don't appear to be connected to anything.

I didn't change anything in the     wifi_nvram_image.h     file. and even did try substituting the slightly different values in 3 places from BCM943362WCD6

and that didn't get rid of the TIMEOUT either.

Any thoughts of what else I should look at when porting a board platform from 3.0.1 to 3.5.2?

And is that the correct terminology "board platform" so as to distinguish it from a "MCU platform"?

0 Likes
1 Solution
Anonymous
Not applicable

While I haven't bottomed out on the complete cause chain, the problem with HT clock not coming up appears to be related to the firmware not being downloaded correctly because the filesystem was not present.

In     wiced_platform_common.c     the call to     platform_filesystem_init()     does not check the return value.

This makes one of the errors not visible. There are similar issues within WWD where error checking could be better. All of this causes     wiced_init()     to return     TIMEOUT (2)     and leading one to think the HT clock is the core issue. Additionally, in most of the example apps, even the return value from     wiced_init()     is not checked, so it's not until later in the app that an error becomes visible.

Further, if the application structure depends upon a filesystem but     USES_RESOURCE_FILESYSTEM     is not defined, there are no errors that report the inconsistency.

Bottom line, HT clock is up and running and so is my app on 3.5.2.

As a minimum, I'd request that 3.6.x     wiced_platform_common.c     be modified from:

#ifdef USES_RESOURCE_FILESYSTEM

    platform_filesystem_init();

#endif

to

#ifdef USES_RESOURCE_FILESYSTEM

    retval = platform_filesystem_init();

    if ( retval != PLATFORM_SUCCESS ){

        WPRINT_WICED_INFO(("platform_filesystem_init: fail\n"));

    }else{

        WPRINT_WICED_INFO(("platform_filesystem_init: success\n"));

    }

#endif

View solution in original post

21 Replies
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

davidep wrote:

Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

The call path is:

wiced_init()

wiced_wlan_connectivity_init()

wwd_management_wifi_on()

wwd_management_wifi_platform_init()

     wwd_bus_init()

and it appears that the problem is occuring in wwd_bus_init()

and the return value if wiced_init() is 2 which is TIMEOUT which implies that some sort of handshake is not occurring properly between the STM32F411 and the 943362.

I do observe this issue occasionally happened in another platform.

Can you confirm if this issue never happen in SDK-3.0.1?

0 Likes
Anonymous
Not applicable

I can only say that on the 3.0.1 that was provided to me (and I'm sure it has been tweaked), it has never happened.

0 Likes
Anonymous
Not applicable

By the way, this is NOT intermittent. It is a hard fail.

0 Likes
Anonymous
Not applicable

Looking further, I can see that the first errors are:

Could not download firmware

Could not initialize bus

Could not initialize

Retval 2; Failed: wiced_init

So it appears that the first few handshakes in      wwd_bus_init()      are successful

but     wwd_download_firmware()      is failing.

Which makes me ask the question: where is the firmware stored? In 3.0.1 a filesystem was being created, but that isn't yet working on the port to 3.5.2.

Is this my problem?

0 Likes
Anonymous
Not applicable

BTW, using the same HW target, everything is always fine in 3.0.1 and the TIMEOUT hard fails using 3.5.2.

The TIMEOUT is in the section "/* Wait until the HT clock is available */"

The immediately prior     wwd_device_core_is_up()     returns     WWD_SUCCESS

Can anyone provide some background on why     ( csr_val & SBSDIO_HT_AVAIL ) == 0      never becomes true?

Note: wwd_bus_read_register_value( BACKPLANE_FUNCTION, SDIO_CHIP_CLOCK_CSR, (uint8_t) 1, &csr_val )

Anonymous
Not applicable

davidep

Which bus interface are you using - SPI or SDIO?

Is the FW download actually happening - i.e. are you reading from external SFLASH and downloading over the bus interface? Please check if the data is being correctly pushed over instead of there being errors

If HT clock is not running - then either no FW was downloaded, or no NVRAM was downloaded, or the FW is corrupted and hence the internal process is not running. I would not suspect NVRAM at this point if the 3.0.1 was working for you.

Anonymous
Not applicable

SPI, selection hard wired to VDD. And yes, I have both 3.0.1 and 3.5.2 up and download to the same dev kit. 3.0.1 boots and runs nicely 3.5.2 does not pass the HT clock check.

From earlier, I wish I had a better understanding of the big picture:

>> Which makes me ask the question: where is the firmware stored? In 3.0.1 a filesystem was being created, but that isn't yet working on the >> port to 3.5.2.

Your question about download from the external SFLASH is starting to confirm my suspicion that it must be stored externally even though the nvram object seems to be part of the app compilation unit - so I thought it was reading from internal MCU flash.

Must there be an external flash and must the filesystem be created / downloded for that download to work?

I didn't see any errors int the download and I think that retval is checked everywhere in WWD, but I have to give that a second look.

Also confusing is why the nvram download is even needed as the docs seem to claim it is placed in OTP which supposedly doesn't need to be re-written over and over. But I digress.

0 Likes
Anonymous
Not applicable

What is your actual HW platform and where did you get the platform files from?

For the STM32F411 the Firmware is stored in external flash due to the lack of internal MCU flash

There should be minimal changes needed to the platform to get this working. Unless someone did not develop the 3.0.1 platform correctly

0 Likes
Anonymous
Not applicable

NVRAM is usually a text file since most module makers don't want to burn anything other than the MAC address into the OTP


Where did you get the OTP documentation from for this module?

0 Likes
Anonymous
Not applicable

That's helpful, but I think everything was fitting in the internal 512MB as my app is small.

That said, I'm focusing on getting the flash filesystem download working, which was accomplished via a platform specific <platform>_targets.mk file in the 3.0.1 implementation. There appears to be more direct makefile support for these features in 3.5.2 such as wiced_sflash.mk, but I'm having to guess how to do it as I can't find a good pattern for that.

As for OTP, I briefly looked at the Broadcom     4339-AN103-R.pdf     and made some interpretation.

The nvram file was provided by a vendor and I do not suspect any issues with it at this time as it compares closely with others except perhaps with some diversity and missing thd parameters - and it works perfectly in 3.0.1 on the same hw target.

My goal is to rule out the flash filesytem and related things by getting those implemented properly in 3.5.2 and then see where the HT clock issue stands as it may be a side effect of not having the sflash setup properly?? Not sure how that could be, but I need that setup properly anyway and then it will be ruled out as an issue as well.

Here's some debug info from some extra printfs I placed in the WWD code, its probably easy to guess where they were placed:

Starting WICED v3.5.2

Platform <redacted> initialised

platform_watchdog_check_last_reset: success

Started ThreadX v5.6

Initialising NetX v5.5_sp1

Creating Packet pools

Init dhcp, etc

wiced_dct_read_lock done

wiced_dct_read_unlock done: country_code: 21333; us is 21333

wwd_wlan_status not up done

host_platform_deinit_wlan_powersave_clock done: pin: 8

host_platform_reset_wifi done: pin: 2

host_platform_init done

not WWD_SPI_IRQ_FALLING_EDGE

Setup the SPI lines 0 1073873920 8

Setup the SPI lines 1 1073873920 12

Setup the SPI lines 2 1073873920 13

Setup the SPI lines 3 1073873920 15

Setup the SPI lines 4 1073873920 14

host_platform_bus_init done

platform_gpio_set_alternate_function done: pin: 8

host_platform_init_wlan_powersave_clock done 0

download_resource(resource 0,addr: 0 size 210624)

download_resource(resource 1,addr: 244796 size 940)

wwd_reset_device_core done 0

HT_AVAIL_TIMEOUT_MS expired. Loop count: 1000, csr_val: 64, looking for SBSDIO_HT_AVAIL: 128

Could not download firmware via SPI

Could not initialize bus

Could not initializeRetval 2; Failed: wiced_init

EpHw2Init done

Found EPHW2CONFIGNUM 2: bitpins:23,18

Success: wiced_dct_read_lock

0 Likes
Anonymous
Not applicable

Based on what you have told me of this HW it should be SDIO based.

Either way - if all you want is to run the SDK on this HW, you just need to port the platform files. The rest of the environment should be the same. You don't need to port any flash writing code etc.

Please look at the BCM943364WCD1 as the reference and copy that to create a version for yourself for the 43362

0 Likes
Anonymous
Not applicable

Why would you think it is SDIO based?

In 3.0.1 (which works nicely), I placed a printf in WICED/WWD/internal/SPI/wwd_bus_protocol.c at line ~708 looking for when     ( ( csr_val & SBSDIO_HT_AVAIL ) == 0 )     becomes true. It shows that it becomes true in about 14 loops (14 msec) and this is in the SPI directory.

Further, 43362 GPIO0 is tied high, which the datasheet shows as selecting SPI.

The board schematic shows only the SPI configuration as well.

Have I missed something here? Is there some other reason that makes you inclined to believe it's not SPI?

0 Likes

We support two types of modules through our module partners (we do not support chip level development outside of our defined module partners)

-Fully integrated modules which include an onboard CPU which is typically connected to the Broadcom radio inside the module via SDIO.  This type of module is typically WICED based and the module partner themselves define the MCU platform. STM32 is typically what we support out of the box, but many module partners also support other MCUs on a direct basis based on pre-defined engagement criteria.

-Radio modules which include support an external CPU which is typically connected to the Broadcom radio outside the module via SDIO.  This type of module is typically Linux based and the module partner again defines the MPU platform. i.MX6 is typically what we support out of the box, but many module partners also support other MPUs on a direct basis based on pre-defined engagement criteria.

Have you engaged with one of our module partners?  They are listed here in the tables found in the 2016 IoT Solutions Guide

0 Likes
Anonymous
Not applicable

Yes, I am working with one of your module partners.

0 Likes
Anonymous
Not applicable

All I wanted was snip.scan working on 3.5.2 with OTA of any flavor working with the module. That seems to be a tall order. I don't understand why.

0 Likes
Anonymous
Not applicable

As I have recommended given your HW platform - Please use the BCM943364WCD1 platform files in SDK 3.5.2

(Please do not try to forward port the platform files from the 3.0.1 to 3.5.2. We have no way to replicate any issues you might have and how to support them.)

Modify the make file to use the 43362 instead

And modify the platform.h and platform.c to match the GPIO and SPI interface on your module

Copy the NVRAM file from the original 3.0.1 platform files you have to this

And then try again

This should work

This particular platform is tested and supported on SPI on SDK 3.5.2

So the only change you are making is the radio FW

The reason this is a tall order as you are claiming is because you are using a module that wasn't designed and supported by its supplier for the WICED SDK and trying to do the work by yourself. And that is a little bit more tricky then using an off the shelf module in the SDK or a module that its supplier will support in the SDK

0 Likes
Anonymous
Not applicable

I did all this (and ended up with virtually the same files) and it behaves the same… no HT clock

0 Likes
Anonymous
Not applicable

Here's an idea... 3.0.1 is NOT available on the Broadcom website..

If I could get a copy of 3.0.1 from you, I can see how it compares with the distribution that I have. Perhaps that will help narrow this down, particularly if these platform files do NOT work with that vanilla copy of 3.0.1.

Can you provide it?

0 Likes
Anonymous
Not applicable

I'm covered on the 3.0.1 request. Thank you.

0 Likes
Anonymous
Not applicable

While I haven't bottomed out on the complete cause chain, the problem with HT clock not coming up appears to be related to the firmware not being downloaded correctly because the filesystem was not present.

In     wiced_platform_common.c     the call to     platform_filesystem_init()     does not check the return value.

This makes one of the errors not visible. There are similar issues within WWD where error checking could be better. All of this causes     wiced_init()     to return     TIMEOUT (2)     and leading one to think the HT clock is the core issue. Additionally, in most of the example apps, even the return value from     wiced_init()     is not checked, so it's not until later in the app that an error becomes visible.

Further, if the application structure depends upon a filesystem but     USES_RESOURCE_FILESYSTEM     is not defined, there are no errors that report the inconsistency.

Bottom line, HT clock is up and running and so is my app on 3.5.2.

As a minimum, I'd request that 3.6.x     wiced_platform_common.c     be modified from:

#ifdef USES_RESOURCE_FILESYSTEM

    platform_filesystem_init();

#endif

to

#ifdef USES_RESOURCE_FILESYSTEM

    retval = platform_filesystem_init();

    if ( retval != PLATFORM_SUCCESS ){

        WPRINT_WICED_INFO(("platform_filesystem_init: fail\n"));

    }else{

        WPRINT_WICED_INFO(("platform_filesystem_init: success\n"));

    }

#endif

davidep wrote:

While I haven't bottomed out on the complete cause chain, the problem with HT clock not coming up appears to be related to the firmware not being downloaded correctly because the filesystem was not present.

In     wiced_platform_common.c     the call to     platform_filesystem_init()     does not check the return value.

This makes one of the errors not visible. There are similar issues within WWD where error checking could be better. All of this causes     wiced_init()     to return     TIMEOUT (2)     and leading one to think the HT clock is the core issue. Additionally, in most of the example apps, even the return value from     wiced_init()     is not checked, so it's not until later in the app that an error becomes visible.

Hi davidep​,

Thanks for your detail report.

I agree with you that the code should check the return value if a function may fail.

However, the question is if wiced_init() fails the device actually is useless.

Which means anything can cause wiced_init() fails needs *fix*.

PS. I do observe sometimes the firmware is not loaded when USES_RESOURCE_FILESYSTEM is defined.

It's pretty easy to identify when this happen because the wlan firmware version message is not display during boot.

Regards,

Axel

0 Likes