1 2 Previous Next 21 Replies Latest reply on May 29, 2016 12:13 AM by AxLi_1746341

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

      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"?

        • 1. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?
          AxLi_1746341

          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?

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

            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.

            • 3. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

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

              • 4. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

                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?

                • 5. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

                  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 )

                  • 6. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

                    daep_2098041

                    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.

                    1 of 1 people found this helpful
                    • 7. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

                      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.

                      • 8. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

                        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

                        • 9. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

                          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?

                          • 10. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

                            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

                            • 11. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

                              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

                              • 12. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

                                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?

                                • 13. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?
                                  MichaelF_56

                                  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

                                  • 14. Re: Porting a board platform from 3.0.1 to 3.5.2 and wiced_init returns 2 WIFI init issue?

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

                                    1 2 Previous Next