4343W wiced driver stuck when sending CMD53

[yash_bhatt1]

Hi,

I have ported the WICED driver for 4343W wifi+bt module from IMRT1020 to NXP K64.

Our module init function is stuck when it starts downloading firmware on the wifi module i.e at wwd_bus_sdio_download_firmware() function. Before firmware download is started, it sends come configuration over SDIO in wwd_chip_specific_socsram_init() function. In this function 4 bytes of data is send and thus CMD53 is invoked.

While debugging we have observed that the command fails because in the transfer complete callback, the handle->data is not null (note that here the interrupt flag is 0x01 which is same as the cases when transfer is success).

What could be the reason for such behavior? As the interrupts show no error we are struggling to figure out what could have gone wrong here.

Thank you.

[yash_bhatt1]

I managed to resolve this issue by disabling MPU.

But now I am stuck with another issue.

After receiving first chunk of data from the Wifi module, when we send data my transmission fails and the interrupt flag is set to 0x200010. Decoding this I see that it is a CRC error. This issue reproduces 100% times and exactly after receiving large chunk of data from WIfi module (during CLM blob downloaded after the first chunk has been sent).

Can you please help me with this?

[kerryzhou]

Hi yash bhatt,

   Thanks for your updated information.

   Do you use any 4343w wiced modue? The same as the RT sdk code?

- Murata 1DX or 1LV M.2 module
- Murata uSD M.2 Adapter

   Could you also share your porting code?

  What's the K64 board you are using? The official FRDM-K64 or your own designed board?

  Please also share some screen shot about the interrupt flag is set to 0x200010, maybe let me to reproduce your issue will more useful to find the root problems.

  I have the FRDM-K64 board and the murata boards, and can use the RT code  work with murata board.

Wish it helps you!

If you still have questions about it, please kindly let me know.

Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[yash_bhatt1]

Hi Kerry,

Thank you for your response.

We are using LSR Sterling LWB module with FRDM-K64.

We have made progress but after making some undesirable changes to the code.

We observed after the first CLM blob transaction is made ( data send + data receive ), when sending the second chunk, only D0, CMD and CLOCK line shows activity (the other 3 lines are stuck high idk why). If we change to code to just use single data line we are able to complete the CLM blob transfer and the subsequent commands also work and we are able to scan for networks (but can not connect yet).

We have taken IMXRT1020 SDK as the reference and ported the code from there itself making the low level changes related to power and SDIO APIs. I am afraid I might not be able to share the code.

We have made one observation that when we read data that is more than 64Bytes in size the subsequent read fails but for data read less than 64 bytes there is no such issue. In the wiced code we see that for data less than 64 bytes, byte mode is used and for more than 64 bytes block mode is used. But I am no SDIO expert and can not figure out what might be causing this issue. We have configured SDIO to use ADMA2 if that rings any bells.

Any help is appreciated.

Thank you.

[kerryzhou]

Hi yash bhatt，

   You mentioned, you porting the IMXRT1020 SDK code to the K64, and using your own SR Sterling LWB module.

    I have a question, do you use your SR Sterling LWB module connect with the MIMXRT1020-EVK board, whether that works or not? Just make sure it is not the hardware issues. After your orginal refering code works with your SR Sterling LWB module, then you also have referenced wave from the RT side, then you can compare it with your K64 porting code.

   Do you have the MIMXRT120-EVK board on your side?

    Because I don't have the SR Sterling LWB module, I just have the official SDK recommended Murata board, so I can't help you to test it directly.

Wish it helps you!

If you still have questions about it, please kindly let me know.

Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[yash_bhatt1]

Hi kerryzhou‌,

Thank you for your response.

Sadly due to covid-19 we are unable to get hold of IMRT-1020 to verify the LSR module setup with WICED SDK. The probability of LSR module being damaged physically is less because we have used it with IMX6 in the past.

By the time we can get hold of IMXRT-1020, do you have any suggestions to make that we can try out?

Also I see that the only difference w.r.t code between RT1020 and K64 is the SDIO driver. Can you help me understand what is the difference between usdhc (RT1020) and sdhc(K64)? could this be an issue?

Thanks again.

[kerryzhou]

Hi yash bhatt,

  Which detail SDK wifi project you are refering now?

About the usdhc and sdhc difference.

You can check the related reference manual

K64:

usdhc has more enhanced function than sdhc.

Please also tell me which detail code you have porting from RT1020 on your side.

Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[yash_bhatt1]

Hi kerryzhou‌,

I am using the "evkmimxrt1020_wiced_ble_4343W" example code.

Also we have observed that when we set the clock to 50mhz the reported clock is 40mhz. Is this kind of offset expected or we are missing something here?

Also for 25mhz we get 24mhz.

[kerryzhou]

Hi yash bhatt，

    If the 50Mhz configuration is 40Mhz in real, and 25Mhz is 24Mhz, it has issues.

    You need to check your clock source, and the related configuration, whether it is correct.

    Please check the clock configuration, make sure the related setting is OK.

    You can check from your original clock source, then check each register configuration, and calculate it.

    After the clock works OK, then check more details about your wifi related code.

  Any updated information, please kindly let me know.

Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[yash_bhatt1]

Hi kerryzhou‌,

I think I miscommunicated. By actual I mean the clock derived after achieving the nearest possible freq to requested freq.

When we request 50Mhz, the clock multiplier and div ends up with 40Mhz, which is returned by "SDMMCHOST_SET_CARD_CLOCK".

I compile the FatFS example and got the same response.

[kerryzhou]

Hi yash bhatt,

  Do you mean, when the SDK defined clock is not the real clock?

  Please tell me how you defined, eg, how you define 50Mhz, and how you find the 40Mhz.

   Then I will help you to check it.

Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------