2 of 2 people found this helpful
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.
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:
Wiced log.txt.zip 874 bytes
1 of 1 people found this helpful
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:
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
Hi! Thanks for your attention SiSa_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?
Wiced log.txt.zip 929 bytes
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 */).
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.
1 of 1 people found this helpful
"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.