CLM blob download failure while transferring second chunk

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

cross mob
YaBh_4672321
Level 3
Level 3
25 replies posted 10 replies posted 10 sign-ins

Hi,

I have interface 4343w with NXP FRDM-K64F. I have ported the wiced sdk taking reference of IMRT1020 example project provided by NXP.

I am so far able to flash firmware and NVRAM image with out any issues. When it comes to downloading CLM blob file, I observe a very weird behaviour.

(Max packet size is set to 1000 from 1500 default)

1. The first chunk of the CLM blob data (size 900 bytes + ioctl packet overhead) is successfully transmitted.

2. Interrupt is received and the wwd_thread goes to receive data. The total data received is of size 956 bytes.

     When printing the data I observed the following:

     - data received contains the sent data i.e the first 900 bytes of CLM blob data is part of the packet.

     - The data received is 12 bytes short of the data sent i.e I get 12 less bytes of CLM blob then what is sent.

     Is this behaviour expected? Flags of the response does not show error.

3. Transmit of second 900 byte chunk of data fails with data CRC error while transmitting.

What can be causing such behaviour?

Please help me out.

0 Likes
1 Solution

Can you provide the wwd stats as described in the test and debug section of this blog : STM32F469 porting in WICED

Also this blog discusses the process of porting and a few general issues that may come up during the port. Can you go through it once and check if all the steps mentioned there are completed?

View solution in original post

0 Likes
5 Replies
Murali_R
Moderator
Moderator
Moderator
250 sign-ins 250 replies posted 100 solutions authored

Hi YaBh_4672321

Was the download successful when the Max Packet size was in its default value of 1500?

Also could you let me know as to why there's a need for changing the max packet size?

Thanks

0 Likes

Hi,

We had changed the packet size just for debug purposes.

The CLM blob download fails even with packet size of 1500.

To update you we have bypassed the issue, we can now flash the CLM blob file BUT we can only do it in One bit mode of SDIO.

We observed that after sending the first packet and receiving back its response, the D[1:3] showed no activity (held high) but D0 did show activity of transferring data. So that prompted us to move to 1 bit mode and bingo we can move ahead.

We still can not connect to network and initial read fails (the 4 byte initial read after the actual response has been received where the host MCU is now expecting "00 00 00 00" to signal no more data. here we dont get any response). Also the KSO function fails to put bus to sleep quite frequently.

Can you help us resolve these issue? What could be the possible cause of D[1:3] getting stuck? and why does bus sleep function fail?

Thank you

0 Likes

I'm not sure but there may be some hardware issue involved and hence there might be an issue with D[1:3]. Did these pins show any activity while downloading the firmware and the nvram?

The network initialization maybe failing(assuming that the device has booted) due to the reduced throughput which would have resulted because of the device's operation in 1 bit mode.

There may have been some issue in the SDIO port too. Could you please give me the reference of the porting guide which you used?

Also is there an OOB interrupt that has been configured or are you using and In band Interrupt?

Hi,

The pins were working perfectly fine while downloading firmware and nvram image.

I am using the IMXRT1020 SDK that has a port for cypress 4433w as a reference to port the wiced to Kinetis K64.

OOB is enabled and we are using OOB.

We have tried different sdio speeds from 10MBPS to 50MBPS but the results are the same.

We have observed one weird behaviour. When we start scanning we receive interrupt for only the first network that is discovered. We then stop receiving interrupts. But if we go from interrupt based transaction to polling mode i.e call receive_one_packet on loop, we get other Ssids. But the scan complete event is not received consistently (even after increasingly the timeout).

We can not connect to network too. We get the join event status 0 and status 3 but then don't receive any more updates from module.

We are not able to figure out reason for such behaviour. Your help will be very much appreciated.

Thank you.

Get Outlook for Android<https://aka.ms/ghei36>

0 Likes

Can you provide the wwd stats as described in the test and debug section of this blog : STM32F469 porting in WICED

Also this blog discusses the process of porting and a few general issues that may come up during the port. Can you go through it once and check if all the steps mentioned there are completed?

0 Likes