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

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

    david_epperly_2098041

      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?
          axel.lin_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?
            david_epperly_2098041

            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.

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

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

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

                  david_epperly_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?
                    david_epperly_2098041

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

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

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

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

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

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

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

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

                                  1 2 Previous Next