Could not turn off TX glomming

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

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>},

0 Likes
1 Solution
Anonymous
Not applicable

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.

View solution in original post

0 Likes
18 Replies
Anonymous
Not applicable

Still looking for feedback...

0 Likes
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

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 );

Anonymous
Not applicable

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?

0 Likes

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.

0 Likes
Anonymous
Not applicable

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

0 Likes

Release mode when  no debug in your make command string.

0 Likes

Re: SDK-3.7.0-7: Device network is unreachable once init bt stack

Find darius1 comments how disable test in debug mode.

0 Likes
Anonymous
Not applicable

Disabling LWIP debug did not help.

0 Likes

user59

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.

0 Likes
Anonymous
Not applicable

@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.

0 Likes

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.

0 Likes
Anonymous
Not applicable

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.

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.

Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

Which type of connection do you use? SDIO 1BIT or 4BIT?

In 1 bit SDIO this timeout is caused due to lack of IRQ line interrupt handling which is normally connected on second dataline of SDIO.

pastedImage_0.png

You should try 1bit sdio and configure faling interrupt on IRQ line to notify wwd thread. Below you can see example communication screenshot in 1bit sdio mode:

pastedImage_1.png

Anonymous
Not applicable

If I remember correctly, its 4 bit mode as its the default in the SDK. This may not be my issue then? My hardware is wired up with 4 Data lines. Besides, isn't what you are suggesting implemented int he SDK already for 1 bit mode?

0 Likes
Anonymous
Not applicable

I suggested you to make test in 1bit mode. It would be easier to found bug with running program.

You can switch wiced sdk to 1bit mode with define SDIO_1_BIT.

0 Likes
Anonymous
Not applicable

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.

0 Likes