Wiced IOCTL timeout semaphore issue

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

cross mob
YuH_4045846
Level 1
Level 1
First like received

Hello!

I deal with adoptation WICED SDK 6.1 to the Cortex-A9 SoC. ThreadX OS is used.

The configuration of my SDIO interface onto SoC:

  • 4-bit bus;
  • 48 MHz speed;
  • connected lines: CMD, CLK, DATA[0..3], WWD_PIN_POWER;
  • external IRQ is not used

Wiced SW config:

  • WWD_DISABLE_SAVE_RESTORE is not initialized;
  • PLATFORM_WLAN_ALLOW_BUS_TO_SLEEP_DELAY_MS is initialized by 10 ms;
  • WICED_USE_WIFI_TWO_STA_INTERFACE is not initialized;
  • WICED_DISABLE_MCU_POWERSAVE is initialized.

There is a known trouble with a waiting of wwd_sdpcm_ioctl_sleep semaphore into ioctl. I found out that mentioned semaphore has to be set with wwd_sdpcm_process_rx_packet() function. The last one function can't be raised if no frame presents on the module. So, there is no new frame (wwd_bus_read_frame(...);) on the module and as consequence semafore can't be reached.

Additionaly, some magic happens if I try to get right value from SDIO_INT_STATUS register. First and last time I've got  SDIO_INT_STATUS = 0x8200C0, but all next time I get 0x20000 value.

As it seems to me

SDIO_INT_STATUS = 0x8200C0 - value contains a flag about receiving the packet.

SDIO_INT_STATUS = 0x020000 - value doesn't contain a flag.

I got the information from the sources:

https://community.cypress.com/thread/4819?q=IOCTL%20timeout%20issue

https://community.cypress.com/thread/1801?q=semaphore%20timeout

https://community.cypress.com/thread/1801?q=timeout%20ioctl

and tried all advices from there but all unsuccessfull.

1.Could you tell me about conditions for the SDIO_INT_STATUS when the correct rx status will appear?

2.What are the special software action should be accept by me for the wwd_sdpcm_ioctl_sleep semaphore managing?             

PS. I will be able to attach the Wiced log if it is needed.

Thanks!

0 Likes
1 Solution

There is a solution of my issue.

I prevented the function checking  of "available to read" before the call of wwd_sdpcm_process_rx_packet(); function into a wiced thread. After this action the issue with semaphore as well as CLM blob downloading are fixed. Further, the program could go to the AP initialization of application_start(); and there is a new trouble with it. Another word, I don't have a possibility to check the SDIO_INT_STATUS regarding to my platform depedency. I am not absolutely sure about this trick, but it works.

Ok, about your questions.

As I mentioned above, the function wwd_sdpcm_process_rx_packet(); was called with size of received packet about 12 bytes (was equal to SDPCM_HEADER_LEN!!!). The last one call happens two times and after that is no longer called because a wwd_bus_read_frame(); function had returned a HWTAG_MISMATCH status.

I modified some declaration into Wiced SDK for the platform compartibility.

The list of my changes will have been published little bit later. Thanks!

View solution in original post

9 Replies
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

Hello:

Do you know what is the meaning about the magic value 0x8200C0  ?

According the description  the normal communication still had some problems, So my suggestions are:

1.  need to check the normal INT status value.

2.  enable WPRINT_WWD_DEBUG and WPRINT_WWD_ERROR to see where block the process in the wiced.

3.   add WWD_BUS_SDIO_RESET_DELAY, I see the default value is 1,  the value can be increase for a try.

Thanks.

lock attach
Attachments are accessible only for community members.

A lot of thanks for you reply!

I shoud say that the trouble with semaphore happens first time at the point of CLM blob file downloading where the send IOVAR first encountered during initialization.

The SDIO_INT_STATUS value has been taken as a result of reading backplane data into a wwd_bus_packet_available_to_read(); function thanks to adding my own dubug info. I am not exactly sure about numbers into this SDIO_INT_STATUS, but I found out that a function wwd_sdpcm_process_rx_packet(); was called with size of received packet about 12 bytes (was equal to SDPCM_HEADER_LEN!!!). The last one call happens two times and after that is no longer called because a wwd_bus_read_frame(); function had returned a HWTAG_MISMATCH status.

You suggesed to check the normal INT. Do you mean interrups of SDIO?

The second and third your recommendations were tested, but without true result. The same issue of semaphore waiting appears.

I attached the log file here.

The log messages with a following text are mine:

<wwd_bus_packet_available_to_read>...

<wwd_thread_func>...

<resource_get_CLM_blob_data>...

0 Likes
SiSa_3185206
Level 4
Level 4
10 likes received First like received First like given

I saw this kind of issue long back on a 43364 WICED board.

For me, it was failing every time when the IOVAR_STR_CUR_ETHERADDR iovar is called from wwd_wifi_get_mac_address function.

If a specific IOVAR / IOCTL command does not return for you and if it happens at the same place all the time, then I have a workaround for you.

Introduce a little delay just before calling the particular IOCTL or IOVAR call.

You can add 100ms delay (just a random value, which worked for me) by using the below API:

host_rtos_delay_milliseconds (100);

Please let me know which command is exactly failing?

Does it fail at the same command or at different commands all the time?

You can use the following tip:

Every IOCTL or IOVAR command goes through wwd_sdpcm_get_ioctl_buffer or wwd_sdpcm_get_iovar_buffer where you can print the command value (if it is IOCTL) or the command string (in case of an IOVAR).

Reference: How to print wifi command info on WICED

lock attach
Attachments are accessible only for community members.

Hi! Thanks for your attention siba_3185206

1. Regarding to the delay, I pasted it into  wwd_sdpcm_send_iovar(...); with 100 ms value.

Due to this fix in the log file I see a new given status of SDIO_INT_STATUS =  0x20420000, but the remaining behaviour stays the same.

2. Adding a log that you suggested gave the last command - "IOVAR Command clmload". The issue of fail always appears at the same command - WLC_SET_VAR.

Additionaly, there is a correct wwd_sdpcm_send_ioctl(...); execution can't be prolonged by the reason of semaphore stucking.

One interesting thing is about how the receive sdpcm sequence should be provided during clm_blob file downloading?

I didn't understand about IOVAR_STR_CUR_ETHERADDR iovar. Could you explain about this one?

Best regards!

0 Likes

If I am not wrong, the clmload is the first IOCTL command that is executed by WICED after bootup.

I suspect that the print statement takes lot of time to execute and for this reason, the IOCTL semaphore is not released.

The timeout value for an IOCTL command is set to 400 milliseconds (WWD_IOCTL_TIMEOUT_MS). The print statement execution time could be more than 400ms.

So, once you remove that print statement and see what is the behavior.

If you really want to trace whether a particular IOCTL command has returned or not; the right place to put a print in the wwd_sdpcm_process_rx_packet() function inside the (case CONTROL_HEADER  /* IOCTL/IOVAR reply packet */).

0 Likes

Thanks!

The WWD_IOCTL_TIMEOUT_MS was rised up to 5000 ms, but semaphore released by this timeout anyway. Print messages were deactivated too.

Of course, a CONTROL_HEADER should be received for the semaphore release, but there is no data into rx packet. The absence of data is a wrong state at this moment and should be found out as It seems to me.

At the moment I'am trying to go deeply into rx process and send command with IOCTL.

0 Likes

"Of course, a CONTROL_HEADER should be received for the semaphore release, but there is no data into rx packet."

Can you please explain what do you mean when you say there is no data into the rx packet??

"The absence of data is a wrong state at this moment and should be found out as It seems to me."

Also, please explain this.

Setting the IOCTL command timeout to 5000ms (5 seconds) is too high.

Does the command failed at default timeout of 400ms??

Did you modify any code in WICED SDK??

There is a solution of my issue.

I prevented the function checking  of "available to read" before the call of wwd_sdpcm_process_rx_packet(); function into a wiced thread. After this action the issue with semaphore as well as CLM blob downloading are fixed. Further, the program could go to the AP initialization of application_start(); and there is a new trouble with it. Another word, I don't have a possibility to check the SDIO_INT_STATUS regarding to my platform depedency. I am not absolutely sure about this trick, but it works.

Ok, about your questions.

As I mentioned above, the function wwd_sdpcm_process_rx_packet(); was called with size of received packet about 12 bytes (was equal to SDPCM_HEADER_LEN!!!). The last one call happens two times and after that is no longer called because a wwd_bus_read_frame(); function had returned a HWTAG_MISMATCH status.

I modified some declaration into Wiced SDK for the platform compartibility.

The list of my changes will have been published little bit later. Thanks!

I will wait for you to publish the code changes. After that I can analyze what is really going on in the execution part!

Please do publish the code if it is okay to do so.

0 Likes