FX3 emmc unreachable after format in manual Part 2

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.
FuBe_4381791
Level 4
Level 4
10 questions asked 50 sign-ins 25 replies posted

Hello Cypress!

This is a continuation of an issue from: FX3 emmc unreachable after format in manual 

The FX3 does not allow the drive to be formatted when set to manual, this is a big issue since we want to encrypt data as it is passed through. The drive becomes unrecognizable after this process, after trying it once, failing, then trying again, the drive does appear as "raw" in device manager, but it is still not format-able. Is there an additional call back that must be added? Please note when firmware is written and the drive is formatted under auto, then reset back to manual, files can be written and read like normal, it is just when trying to format the drive in manual that this fails.

I apologize I can't seem to post a reply to the previous thread so creating a new one. I have tested this on a different FX3 with a different flash chip and the issue persists. Please see the attached project file which is a very slightly modified version of the MSC example and these videos, to find the places where changes were made in the zip, search for the define "Manual_MSC". It is used in 3 places.

Video of failure to format to FAT with explorer, succeeding when switched back to auto mode, then failing again when trying to format in NTFS, and explorer crashed at the end too...

https://drive.google.com/file/d/10jToAssyamGRbILLY7TkheYB-1YNGdFD/view?usp=sharing

Video of formatting drive with device manager, FX3 just stopped working at the end, it was still connected.

https://drive.google.com/file/d/1dZg9Mp7ySYX7QscVTuNORb6bXTlYEx4C/view?usp=sharing

I have also tried other formatting tools and this still fails.

Is there a call back that is missing in: CyFxMscApplnDmaCb? Or is there a response that is meant to be added to CyFxMscApplnUSBSetupCB? 

Regards!

Fujimi

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.

Hello Rashi!

For some reason the timer callback method causes the operation to throw a mutex error, I think it's because it's calling from a callback.

Using a separate thread with flags, it worked, I've attached a working manual MSC project incase someone else runs into something similar... Please note that since there is no way to determine if the partially filled buffer was fully received, I've used the count of bytes as the check for disabling checkfor_last_irregular_packet, not just if CyU3PDmaChannelSetWrapUp returned success.

Thank you for all the help, this is resovled!

Regards

Fujimi

Addendum: This is working for USB 3 where packets are 4096, I have not tested this on USB 2 where packets should be smaller, the check for size is on line 1451 where it compares number of blocks in request for the irregular sized data which would cause a partially filled buffer.

Double addendum: The method for checking the number of block to see if the request would cause a partial buffer does NOT work for USB2,  when a write request of a single block happens, the producer will not trigger... I think a better method will be to always use a timeout, I will post a working USB2 and USB3 example (cleaned up too, realized I'm doing some weird things). It's very strange that USB3 has different DMA behaviour to USB2....

Cause reading that above confuses myself, to simplify what I mean:

if buffer size is X, Data write in is Y, then:

USB3: if Y<X OR Y%X == 0 it works, otherwise partial buffer issue

USB2: if Y%X == 0 it works, otherwise partial buffer issue

View solution in original post

0 Likes
49 Replies
lock attach
Attachments are accessible only for community members.

Hello Rashi!

I've attached debug output, good spot I thought I would of had both of them as 511, my mistake.

"From the AUTO and MANUAL UART prints I understand that USB reset events are seen only when MANUAL channel is used. Please confirm if same procedure is used for format in both the scenarios": Yes the exact same procedure was used, literally just:
1. program 2. wait a few seconds for drive to appear 3. output debug via GPIO trigger and serial monitor 4. Run windows format 5. wait for response from format operation (success or fail, fail does take awhile though) 6. output debug

Regards!

Fujimi

0 Likes

Hello Rashi, I created this to make it abit clearer, hopefully this is helpful: https://docs.google.com/spreadsheets/d/1PvcgSmN0EjbvxJbwIOMuo_kqi3KtbGoDazTx5TtKG48/edit?usp=sharing

I'm guessing there is a callback missing from XFER complete but not sure...

Regards!

Fujimi

0 Likes

Hello  Fujimi,

Thank you for sheet. It was really helpful!

From the sheet (USB 3.0 & USB 2.0), I could see that Write transfer fail with CYU3P_XFER_TIMEOUT when CY_U3P_SIB_EVENT_XFER_CPLT is triggered.

While going through the source, I could find that the event is triggered when the write timer expires and CY_U3P_SIB_TIMERx_EVT is set. 

Also, once the WRITE_10 fails for 3 times, the USB host doesn't send the WRITE request (CBW).

Regards,
Rashi
0 Likes

Hello Rashi!

Yes that's the conclusion I came up with too. I've tried changing timeout with CyU3PSibWriteTimerModify(CYU3P_WAIT_FOREVER); in SIB init before SIB is started, but this does not resolve the issue. I do not understand why a timeout error occurs in the first place?

From my understanding, a commit is been missed from the callback causing the timeout to occur? Would it be better to not use any callback and try to handle the SIB operation with wait for DMA to complete? I don't know how it would be able to handle large amounts of data though since it would need to iterate over each buffer?

Regards!

Fujimi

0 Likes

Hello Fujimi,

 I've tried changing timeout with CyU3PSibWriteTimerModify(CYU3P_WAIT_FOREVER);

>> Please let me know the error seen for this case

From my understanding, a commit is been missed from the callback causing the timeout to occur?

>> To confirm this can please check the return status of CyU3PDmaChannelCommitBuffer. This will help us to understand that the CyU3PDmaChannelCommitBuffer never fails/misses

Would it be better to not use any callback and try to handle the SIB operation with wait for DMA to complete? I don't know how it would be able to handle large amounts of data though since it would need to iterate over each buffer?

>> From this, I understand you meant that using the DMA channel in override mode as done for receiving CBW an sending CSW. Is that correct? If yes, we can try that after checking if the commit returns failure.

Also, as the debug prints for all the events in CyFxMscApplnSibCB are common. Please confirm if only CY_U3P_SIB_EVENT_XFER_CPLT event is seen.

Can you please check if CyU3PSibReadWriteRequest in CY_FX_MSC_SCSI_WRITE_10 returns success every time?

Off the topic, please make the appropriate changes as per this thread Solved: FX3S example applications questions DMA reset - Cypress Developer Community to the firmware (based on fx3smasstorage) to avoid any future issues

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

Hello Rashi!

Thanks again for your time on the call!

Just letting you know I've tried using the API: CyU3PDmaChannelSetWrapUp (&glChHandleMscOut);

I've attached the project and the output from the debug to this message, it does not seem to trigger the last part of packet either, but I can see that the timer I've set up, is triggering at the correct time (debug code Q).

Is there an example usage for CyU3PDmaChannelSetWrapUp? From it's description it seemed like what was needed but I don't see the producer's callback.

Regards!

Fujimi

Edit: I just realized CyU3PDmaChannelSetWrapUp is getting CY_U3P_ERROR_MUTEX_FAILURE, so it is not working, I probably can not call it in the timer function.... Not sure where I would be able to call it in normal code, will keep trying

0 Likes

Hello Fujimi,

You can set an event in the timer callback when the conditions are true.

Call a CyU3PEventGet and then call CyU3PDmaChannelSetWrapUp  API to wrap up the USB  socket and get a producer event for the partially filled buffer. If the CyU3PDmaChannelSetWrapUp  returns success, make checkfor_last_irregular_packet false so that the event is not set the next time.

Please adjust the timer for SIB request using CyU3PSibWriteTimerModify such that the CYU3P_XFER_TIMEOUT  is not triggered. 

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

Hello Rashi!

For some reason the timer callback method causes the operation to throw a mutex error, I think it's because it's calling from a callback.

Using a separate thread with flags, it worked, I've attached a working manual MSC project incase someone else runs into something similar... Please note that since there is no way to determine if the partially filled buffer was fully received, I've used the count of bytes as the check for disabling checkfor_last_irregular_packet, not just if CyU3PDmaChannelSetWrapUp returned success.

Thank you for all the help, this is resovled!

Regards

Fujimi

Addendum: This is working for USB 3 where packets are 4096, I have not tested this on USB 2 where packets should be smaller, the check for size is on line 1451 where it compares number of blocks in request for the irregular sized data which would cause a partially filled buffer.

Double addendum: The method for checking the number of block to see if the request would cause a partial buffer does NOT work for USB2,  when a write request of a single block happens, the producer will not trigger... I think a better method will be to always use a timeout, I will post a working USB2 and USB3 example (cleaned up too, realized I'm doing some weird things). It's very strange that USB3 has different DMA behaviour to USB2....

Cause reading that above confuses myself, to simplify what I mean:

if buffer size is X, Data write in is Y, then:

USB3: if Y<X OR Y%X == 0 it works, otherwise partial buffer issue

USB2: if Y%X == 0 it works, otherwise partial buffer issue

0 Likes

Hello Fujimi,

We are glad to hear that the problem is resolved!

Regards,
Rashi
0 Likes
FuBe_4381791
Level 4
Level 4
10 questions asked 50 sign-ins 25 replies posted

Hello Rashi!

I am abit more confused, the CY_FX_MSC_SCSI_MODE_SENSE_6 has handle for 0x1A, from what I can find, 1A is for power...

Regards!

Fujimi

0 Likes