1 2 Previous Next 18 Replies Latest reply on May 11, 2017 10:28 AM by gorac_2135286

    Could not turn off TX glomming

      I am trying to bring up the manufacturing test 43438 wifi firmware 43438A1-mfgtest.bin to read its capabilities. However, I fail with the error: "Could not turn off TX glomming" due to missing IOCTL response. I am looking for suggestions to figure out if the wifi core is sending the response late or is the arm core not processing the received response due to a higher priority task hogging resources on FreeRTOS.

       

      Debugging so far:

       

      1. wwd_management_wifi_on() performs the following call which always times out. The 3.7.0 SDK has set the timeout to 400 ms. Even if I make the timeout 10x it does not help.

      data = (uint32_t*) wwd_sdpcm_get_iovar_buffer( &buffer, (uint16_t) 4, IOVAR_STR_TX_GLOM );

      retval = wwd_sdpcm_send_iovar( SDPCM_SET, buffer, 0, WWD_STA_INTERFACE );

      2. The mfg_test_init.c does not handle the failure so it makes the following call anyway:

      wwd_wifi_set_iovar_value( IOVAR_STR_MPC, 0, WWD_STA_INTERFACE );

      3. As soon as the following call happens, the wwd_thread runs and finds the the response to the first IOVAR and drops it saying its waiting for the response to the second. It also receives the second response in quick succession.

       

      Since, the second response comes in quick succession it seems like the SDIO_irq is working and the first response was truly delayed by the wifi core.

       

      I enabled the SDPCM logs and see the following:

      {direction = LOG_TX, type = IOCTL, time = 190, length = 47,

            header = "...bus:txglom",

      '\000' <repeats 53 times>},

      {direction = LOG_TX,

            type = IOCTL, time = 706, length = 40,

            header = "...mpc\000\000\000\000\000om",

      '\000' <repeats 53 times>},

      {direction = LOG_RX, type = IOCTL, time = 708, length = 47,

            header = "...bus:txglom",

      '\000' <repeats 53 times>},

      {direction = LOG_RX,  type = IOCTL, time = 718, length = 40,

            header = "...mpc\000\000\000\000\000om",

      '\000' <repeats 53 times>},

        • 1. Re: Could not turn off TX glomming

          Still looking for feedback...

          • 2. Re: Could not turn off TX glomming
            GauravS_31

            Which Wiced platform are you using? Is this problem reproducible or intermittent? Are you getting this problem while running test.console app? It is possible that your hardware is bringing up the bus faster but the WLAN chip is not ready to receive the first iovar. Add a 1/10/50ms delay before the first iovar is sent to the wlan chip as shown below in wwd_management.c:

             

            host_rtos_delay_milliseconds(10);

            data = (uint32_t*) wwd_sdpcm_get_iovar_buffer( &buffer, (uint16_t) 4, IOVAR_STR_TX_GLOM );

            1 of 2 people found this helpful
            • 3. Re: Could not turn off TX glomming

              I am seeing this issue on the Murata Type 1HD and 1LD module. This issue is always observed 100%. I am getting the error while running the test.mfg_test app. Since I posted my query, I did some more debugging here are additional details of what I observe:

              1. Increasing the IOVAR timeout did not help. Neither did adding delays before the IOVAR call. I had tried delays up to 15 seconds!

              2. The first response always arrives as soon as the second IOVAR/IOCTL request is made irrespective of the delay above.

              3. There are no sdio_irq or sdio_dma_irq events between first request and second request.

              To me this is almost as if the response is not being processed because the interrupt is somehow disabled between request 1 and request 2. However, I am not sure how to setup a test to confirm my hypothesis.

               

              Any suggestions?

              • 4. Re: Could not turn off TX glomming
                DaBa_2244756

                Hi,

                At debug mode for freertos is enabled  memory test. This test executed at switch time and it disabling interrupts for 2ms.

                Try release mode or disable this tests  if you want use debug.

                • 5. Re: Could not turn off TX glomming

                  I can try that. Can you provide more info? I am not familiar with what you are saying.

                  • 6. Re: Could not turn off TX glomming
                    DaBa_2244756

                    Release mode when  no debug in your make command string.

                    • 7. Re: Could not turn off TX glomming
                      DaBa_2244756

                      The specified item was not found.

                       

                      Find darius1 comments how disable test in debug mode.

                      • 8. Re: Could not turn off TX glomming

                        Disabling LWIP debug did not help.

                        • 9. Re: Could not turn off TX glomming
                          MichaelF_56

                          gorac_2135286

                           

                          As a strategic module partner, you should be using the MyCases method to submit questions to the level 2 and 3 applications teams.

                           

                          If you go to cypress.com, login, then look at the menu under your username in the top right corner, you will see the feature appear.

                           

                          Can you submit this question to MyCases so that support can be prioritized.

                          • 10. Re: Could not turn off TX glomming

                            @mifo: I have created ticket 00327685. You had recommended something like this to me for the previous case and that has not received any answers for almost 2 weeks.

                            • 11. Re: Could not turn off TX glomming
                              AxLi_1746341

                              mifo wrote:

                               

                              user59

                               

                              As a strategic module partner, you should be using the MyCases method to submit questions to the level 2 and 3 applications teams.

                               

                              Then other users on the forum won't get any benefit and the similar question will be asked again and again.

                              Besides, your team seems does not active response on MyCases.

                              • 12. Re: Could not turn off TX glomming
                                AxLi_1746341

                                grsr wrote:

                                 

                                Which Wiced platform are you using? Is this problem reproducible or intermittent? Are you getting this problem while running test.console app? It is possible that your hardware is bringing up the bus faster but the WLAN chip is not ready to receive the first iovar. Add a 1/10/50ms delay before the first iovar is sent to the wlan chip as shown below in wwd_management.c:

                                 

                                host_rtos_delay_milliseconds(10);

                                data = (uint32_t*) wwd_sdpcm_get_iovar_buffer( &buffer, (uint16_t) 4, IOVAR_STR_TX_GLOM );

                                Such delay is a dangerous thing because it might work for one device but does not work for another device.

                                If you think the problem is h/w not yet ready, you need to polling the h/w status until it's ready.

                                1 of 1 people found this helpful
                                • 13. Re: Could not turn off TX glomming

                                  I went one more layer deeper and looked at the pending SDIO interrupts after my IOVAR times out. I see the SDIO_IT bit is set however the previous sdio_irq did not clear the bit and call wwd_thread_notify_irq(), probably because the bit was not set at that point.

                                   

                                  I was studying the SDK 3.7.0 code yesterday and was unable to understand why SDIO_MASK_SDIOITIE bit is not set for STM32F412xG in the function below:

                                   

                                  static void sdio_enable_bus_irq( void )

                                  {

                                  #if defined(STM32F412xG)

                                      SDIO->MASK = SDIO_MASK_CMDRENDIE | SDIO_MASK_CMDSENTIE;

                                  #else

                                      SDIO->MASK = SDIO_MASK_SDIOITIE | SDIO_MASK_CMDRENDIE | SDIO_MASK_CMDSENTIE;

                                  #endif

                                  }

                                   

                                  This means sdio_irq will not be called directly for SDIO_IT but it would only be checked if the sdio_irq is entered for a different reason.

                                  1 of 1 people found this helpful
                                  • 14. Re: Could not turn off TX glomming

                                    I added some code to read SDIO Status register at the following points in time:

                                    1. Entering sdio_irq: 0x00045040 <-Bit 22 not set

                                    2. At the end of sdio_irq: 0x00105000 <-Bit 22 not set

                                    3. At timeout of the IOVAR call after 400 ms: 0x00400500 <-Bit 22 (SDIOIT) is set

                                     

                                    This shows that while in the SDIO irq, the SDIOIT bit is not yet set. This prevents the wwd_thread_notify_irq() from being called, leading to a timeout. However, after timeout the bit is set. Since, in stm32f412xG, wiced SDK does not enable the SDIO IT bit in the SDIO mask register it does not trigger the sdio_irq.

                                    I believe this is causing an issue. The reason for the hw taking 400 ms when it normally requires less than 10 ms is not clear.

                                    1 2 Previous Next