Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?
The call path is:
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?
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.
By the way, this is NOT intermittent. It is a hard fail.
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?
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 )
1 of 1 people found this helpful
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.
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.
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
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?
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
Started ThreadX v5.6
Initialising NetX v5.5_sp1
Creating Packet pools
Init dhcp, etc
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
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
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
Found EPHW2CONFIGNUM 2: bitpins:23,18
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
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?
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 IoT Solutions Guide
Yes, I am working with one of your module partners.