- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"?
Solved! Go to Solution.
- Labels:
-
SDK 3.x
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By the way, this is NOT intermittent. It is a hard fail.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 )
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I am working with one of your module partners.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did all this (and ended up with virtually the same files) and it behaves the same… no HT clock
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm covered on the 3.0.1 request. Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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