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
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Fujimi,

To understand the requests received by the FX3S when the format is done. Please add the below debug print in the CyFxMscApplnUSBSetupCB function of firmware and enable LOG_ENABLE macro to get the UART prints.

CyBool_t
CyFxMscApplnUSBSetupCB (
        uint32_t setupdat0, /* SETUP Data 0 */
        uint32_t setupdat1  /* SETUP Data 1 */
    )
{
    CyBool_t isHandled = CyFalse;
    uint8_t  ep0Buf[2];

    uint8_t  bRequest, bReqType;
    uint8_t  bType, bTarget;
    uint16_t wValue, wIndex, wLength;

    /* Decode the fields from the setup request. */
    bReqType = (setupdat0 & CY_U3P_USB_REQUEST_TYPE_MASK);
    bType    = (bReqType & CY_U3P_USB_TYPE_MASK);
    bTarget  = (bReqType & CY_U3P_USB_TARGET_MASK);
    bRequest = ((setupdat0 & CY_U3P_USB_REQUEST_MASK) >> CY_U3P_USB_REQUEST_POS);
    wValue   = ((setupdat0 & CY_U3P_USB_VALUE_MASK)   >> CY_U3P_USB_VALUE_POS);
    wIndex   = ((setupdat1 & CY_U3P_USB_INDEX_MASK)   >> CY_U3P_USB_INDEX_POS);
    wLength  = ((setupdat1 & CY_U3P_USB_LENGTH_MASK)  >> CY_U3P_USB_LENGTH_POS);
 
    
    AppDebugPrint(4, "\n\r bType = 0x%x, bRequest = 0x%x, wValue = 0x%x, wIndex = 0x%x, wLength= 0x%x",
    		bType, bRequest, wValue, wIndex, wLength);
    /* Some setup requests have to be handled in a non-standard way for this device. */
    if (bType == CY_U3P_USB_STANDARD_RQT)
    {.....

 

Please share the UART prints for both the tests 1) AUTO and 2) MANUAL

Also, please let me know if the data transfers (read/write) to the card is done successfully with MANUAL channel i.e. without formatting the card.

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

Hello Rashi!

Thanks for the fast reply!

I do not have UART, this is a custom board. I will investigate the call backs in CyFxMscApplnUSBSetupCB

For this question: Also, please let me know if the data transfers (read/write) to the card is done successfully with MANUAL channel i.e. without formatting the card.

Yes, 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.

Regards!

Fujimi

0 Likes

Hello Fujimi,

You can try capturing USB traces using software analyzer like Wireshark to check the USB requests sent by the host when the disk format is done on the host.

Regards,
Rashi
0 Likes
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 Rashi!

I have attached the output from wireshark USB capture, I tried to limit it only to the formatting operation.

So I clicked on "start capturing" then "ok to format", then waited until windows reported failure, then stopped capturing. I can make a video if it would help?

Out of curiosity, are you able to replicate this issue with the firmware project sent above?

Regards! I did notice that it seems to go through read and write of the hash table.

Fujimi

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

Hello again Rashi!

I repeated this over USB2, there is WAY less in the capture file so I think would be much easier to go through.

Strongly recommend checking this USB2 file instead of the previous one.....

Regards!

Fujimi

0 Likes

Hello Fujimi,

Thank you for the Wireshark traces.

Can you please share the Wireshark traces for the working case (i.e. AUTO DMA channel)?

In the traces shared, I could see multiple class specific requests sent by the host. I noticed that Mode sense (6) requests fails every time. To confirm the USB request sequence from the host, please help me by sharing the USB traces (Wireshark) for the working case.

Also, let me know reason of using CyU3PUsbEpEvtControl without calling CyU3PUsbRegisterEpEvtCallback

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

Hello Rashi!

Please see the attached wireshark output from successful format using Auto. I tried to limit the period of capture to the format operation, but it still came out pretty big.

Please disregard those calls to CyU3PUsbEpEvtControl, they are left over from trying a bunch of different things in the main project which I can't share. I had copy pasted the relevant changes to the original MSC example to demonstrate the format issue.

What is Mode sense 6?

Regards!

Fujimi

0 Likes

Hello Fujimi,

Thank you for the traces.

After comparing the traces, I could see that CY_FX_MSC_SCSI_WRITE_10 fails as the  CSW returns data residue as 512 bytes (which is equal to the bytes written by the host). It means that data is not written to card.

From the firmware, I understand that for both the channels glChHandleMscOut and glChHandleMscIn same DMA callback is used. Can you try using different DMA callback for both the channels and handle the events appropriately. Please check if CY_U3P_DMA_CB_PROD_EVENT event is seen for glChHandleMscOut channel when data format is done. It seems that the data received from the host is not committed to SIB

Kindly, check if the data is received by FX3S when CY_FX_MSC_SCSI_WRITE_10 command is issued during card formatting or can you check the return status of returned by CyFxMscApplnSibCB when CY_FX_MSC_SCSI_WRITE_10 fails.

 

Regards,
Rashi
0 Likes

Hello Rashi!

I have tried separating the DMA callbacks which did not resolve the issue. I don't see anything failing with the SIB call back... But it is difficult without UART debugger.

 

I will keep investigating but I am curious if you are able to replicate this? If this is an issue with our PCB as it is a custom board, I would like to confirm it as soon as possible.

My main confusion is that this operation for write is used in normal read and write which does work if the drive is formatted in Auto... The part that it seems to be failing on is writing the start of the drive?

Regards!

Fujimi

0 Likes

Hello Fujimi,

Reproducing the problem is currently not possible at my end, due to hardware constraints. We are trying to get the hardware to reproduce the problem.

The part that it seems to be failing on is writing the start of the drive?

>> From the USB traces, I could see that 

Please let me know if the problem is seen in USB 3.0 as well CY_FX_MSC_SCSI_WRITE_10 where  CSW is sent with failure code. From the firmware, this could happen when CyFxMscApplnSibCB returns  failure. Please check if CyFxMscApplnSibCB returns failure when format is done when channel is MANUAL. 

Regards,
Rashi
0 Likes

Hello Rashi!

I am still investigating the issue, I have found that in CY_FX_MSC_SCSI_WRITE_10, the operation: status = CyU3PSibReadWriteRequest (CY_FX_SIB_WRITE, ((lun >= CY_FX_SIB_PARTITIONS) ? 1 : 0), glLunUnit[lun], numBlks, startAddr, 0);

Throws the status: "CY_U3P_ERROR_INVALID_DEV"

From checking the variables passed in: lun == 0, glLunUnit[lun] == 3. Both of these variables seem ok so I am confused about why it would say device is invalid, perhaps an operation before it is resetting the drive?

I am still trying to a few bandaid ways around this since it only seems to occur on formatting.

Regards!

Fujimi

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

Hello Fujimi,

Thank you for the details.

CY_U3P_ERROR_INVALID_DEV status is seen when  port with no connected storage device is accessed.

I have modified the firmware you had shared to debug the reason failure of CyU3PSibReadWriteRequest. I have added CyU3PSibIsAddrValid_check function before CyU3PSibReadWriteRequest in CY_FX_MSC_SCSI_WRITE_10, which is similar to the implementation done in CyU3PSibReadWriteRequest API. Please let me know the return status of CyU3PSibIsAddrValid_check

 

Regards,
Rashi
0 Likes

Hello Rashi!

I had to modify it slightly since it stopped the format process entirely, this is the code I used:

uint32_t startAddr2;
startAddr2 = startAddr;
startAddr2 += CyU3PSibLunGetStartAddr (((lun >= CY_FX_SIB_PARTITIONS) ? 1 : 0), glLunUnit[lun]);
status = CyU3PSibIsAddrValid_check (((lun >= CY_FX_SIB_PARTITIONS) ? 1 : 0), glLunUnit[lun], numBlks, startAddr2);
if (status != CY_U3P_SUCCESS)
{
if (status == CY_U3P_ERROR_INVALID_ADDR){
CyFxAppErrorHandler(1);
}
if (status == CY_U3P_ERROR_INVALID_UNIT){
CyFxAppErrorHandler(2);
}
if (status == CY_U3P_ERROR_INVALID_DEV){
CyFxAppErrorHandler(3);
}
}

The result is: status == CY_U3P_ERROR_INVALID_DEV

I think a previous operation is causing the drive to stop working? I'm not seeing any instances of de-init of the drive though. Please note I can get feedback from the error handler.

Regards!

Fujimi

0 Likes

Hello Fujimi,

CY_U3P_ERROR_INVALID_DEV is returned when the address is not valid or the card is not detected.

I have compared the USB traces that you had shared earlier when the card format is done for MANUAL and AUTO channels. I could see the failure happens when WRITE (10) command is received. Please confirm if only Card format was performed while capturing the USB traces with AUTO and MANUAL mode.

I could see following commands from host before WRITE (10) command

- Mode Sense (6) -  Manual /Auto channel not used as the channel is used in Override mode i.e. using CyFxMscApplnSendDataToHost

- Read Capacity -  Manual /Auto channel not used as the channel is used in Override mode i.e. using CyFxMscApplnSendDataToHost

- Inquiry LUN -  Manual /Auto channel not used as the channel is used in Override mode i.e. using CyFxMscApplnSendDataToHost

The changes that are done in the firmware i.e. AUTO to MANUAL applies when WRITE (10) command is received. The MANUAL DMA channel (glChHandleMscOut)will be enabled when CyU3PDmaChannelSetXfer is called. 

From the test, we could see that CyU3PSibReadWriteRequest returns CY_U3P_ERROR_INVALID_DEV which happens when the card is not accessible. 

To check if the data is read from the SD card when WRITE (10) is received, please check if CY_U3P_DMA_CB_PROD_EVENT is received for glChHandleMscOut . Please modify the DMA callback as follows and let me know the value of data_read_from_SD (global variable)

#ifdef Manual_MSC
        case CY_U3P_DMA_CB_PROD_EVENT:

        	if(handle == &glChHandleMscOut)
        	{
        		data_read_from_SD++;
        		CyU3PDmaChannelCommitBuffer (handle, input->buffer_p.count, 0);
        		
        	}
        	else
               CyU3PDmaChannelCommitBuffer (handle, input->buffer_p.count, 0);
break;
#endif

 

Regards,
Rashi
0 Likes

Hello Fujimi,

Apologies for the confusion.

To check if the data is read from the SD card when WRITE (10) is received, please check if CY_U3P_DMA_CB_PROD_EVENT is received for glChHandleMscIN . Please modify the DMA callback as follows and let me know the value of data_written_from_USB (global variable)

#ifdef Manual_MSC
        case CY_U3P_DMA_CB_PROD_EVENT:

        	if(handle == &glChHandleMscOut)
        	{
        		data_read_from_SD++;
        		CyU3PDmaChannelCommitBuffer (handle, input->buffer_p.count, 0);
        		
        	}
        	else
{
               data_written_from_USB++
               CyU3PDmaChannelCommitBuffer (handle, input->buffer_p.count, 0);
}
break;
#endif

 

Regards,
Rashi
0 Likes

Hello Rashi!

To answer this question: "Please confirm if only Card format was performed while capturing the USB traces with AUTO and MANUAL mode."

Yes, only card format was performed in the trace, I first programmed the fx3, after waiting a few seconds for drivers, started the trace, then immediately formatted the drive, after the failure pop up appeared, stop tracing.

The results I get is: 

global variable from taking both sides after format
BOTH
data_read_from_SD 39
data_written_from_USB 76

CyFxMscApplnDmaCbout only
data_read_from_SD 39
data_written_from_USB 0

CyFxMscApplnDmaCbin only
data_read_from_SD 0
data_written_from_USB 73

I tried separating the in and out callback just to double check, and the output seems consistent.... I do not know what this shows? I did get a slight difference with: data_written_from_USB , but I think that's with how fast I performed the format after programming the fx3.

Regards!

Fujimi

0 Likes

Hello Fujimi,

I tried separating the in and out callback just to double check, and the output seems consistent.... I do not know what this shows?

>> Can you please share the latest modified firmware. This will help me to understand the values better.

Also, please confirm if the following value is for AUTO channel  and the other CyFxMscApplnDmaCbout only  and CyFxMscApplnDmaCbin only is for manual channel. Is that correct?

global variable from taking both sides after format
BOTH
data_read_from_SD 39
data_written_from_USB 76

If not, please let me know the values for AUTO channel also.

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

Hello Rashi!

I have attached the modified project, values when run in AUTO are 0 and 0. This makes sense since the event listener for: CY_U3P_DMA_CB_PROD_EVENT is not used in the callback.....

The method used to output values is to flash LED's, I have another project which I can not share that sends values over HID so they have been confirmed.

Q: "Also, please confirm if the following value is for AUTO channel  and the other CyFxMscApplnDmaCbout only  and CyFxMscApplnDmaCbin only is for manual channel. Is that correct?"

A: No it's all manual, AUTO produced 0 values only. I realize now that: 

"if(handle == &glChHandleMscOut) { " in your code had the same effect as separating the call back channels, hence:

BOTH (manual mode, using the same callback)
data_read_from_SD 39
data_written_from_USB 76

CyFxMscApplnDmaCbout only  (manual mode, separated callbacks)
data_read_from_SD 39
data_written_from_USB 0

CyFxMscApplnDmaCbin only  (manual mode, separated callbacks)
data_read_from_SD 0
data_written_from_USB 73

Is unnecessary information and didn't do anything but confuse sorry....

To help you look through the code, in cyfx3s_msc.c:

1.value output via LED's lines 50 to 193
2.CyU3PSibIsAddrValid_check code line 508
3.Write_10 is at line 1294, this includes the point where the output is LED flashed on line 1330
4.remove the comment on line 1336 when trying to force the LED to output using auto during a format, as it does not throw errors normally
5.global variables usage lines: 1910 and 1964 in the separated callbacks

Regards!

Fujimi

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

Hi Fujimi,

Please use the attached firmware and let me know the values of  global variables used in separated callbacks for both AUTO_SIGNAL and MANUAL channel. To get the callbacks for AUTO channel, I have changed the channel to AUTO_SIGNAL.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi!

AUTO_SIGNAL:

data_read_from_SD = 49, data_read_from_USB = 0

Manual: 

data_read_from_SD = 98, data_read_from_USB = 0

Regards!

Fujimi

0 Likes

Hello Fujimi,

Please let me know the values of following variables also

- data_written_to_USB and data_written_to_SD

Please comment out the CyU3PSibIsAddrValid_check from all the instances in the firmware.

Also, let me know if it is possible to access the UART on your board. Without the debug prints it is a bit difficult to debug the issue as currently we are not able to reproduce the issue at our end.

In addition to this, please let me know if the device always comes up as USB 3.0 and the problem is seen when connected as  USB 3.0. 

From the values of data_read_from_SD for both channel, the value is double for MANUAL case. Please check if for both cases the connection is USB 3.0. 

Also, I have noticed that GPIO are used to control LEDs when error is seen. Please let me know which API fails when the LED blinks.

Regards,
Rashi
0 Likes

Hello Rashi!

We've been making a new debug board with a CY7C65215 chip to give more useful feedback. Hopefully done this or next week.

To answer the question: Please let me know which API fails when the LED blinks.

This occurs in write_10 whenever any drive operation is attempted, as the drive is "CY_U3P_ERROR_INVALID_DEV". I forced this when trying to get feedback on the global variables in auto mode.

For questions about variables, I will wait for the UART dev board.

I just discovered that adding the manual flag breaks when trying to copy a file using USB2 and writing, for some reason write works on USB 3 though, to replicate, on the original MSC sample in the SDK, with either the FX3 on a USB2 cable or on a USB3 cable with CyU3PConnectState (CyTrue, CyFalse); in both cases I can not write to mass storage when  CY_U3P_DMA_TYPE_MANUAL is used.

With a USB3 cable and CyU3PConnectState (CyTrue, CyTrue); and CY_U3P_DMA_TYPE_MANUAL, I can write to the drive... 

To summarize cause this is really weird to me:

1. USB2 and USB3 in auto DMA and Mass storage read/write/format works

2. USB2 mode, manual DMA and mass storage can read, not write/format

3. USB3 mode, manual DMA and mass storage can read and write, not format

I do not know what could cause this... Perhaps a callback or another operation is missing? Apart from CY_U3P_DMA_CB_PROD_EVENT and CyU3PDmaChannelCommitBuffer (handle, input->buffer_p.count, 0);

Is there a way to encrypt data before it is sent to the mass storage in auto mode? What exactly does auto do that manual does not?

Regards!

Fujimi

0 Likes

Hello Fujimi,

Thank you for the details

I do not know what could cause this... Perhaps a callback or another operation is missing? Apart from CY_U3P_DMA_CB_PROD_EVENT and CyU3PDmaChannelCommitBuffer (handle, input->buffer_p.count, 0);

>> Please do the the following changes in the CyFxMscApplnDmaCbout and let me know values of  data_read_from_USB and data_written_to_SD when write to the drive is done. Also let me know if write fails with USB 2.0/USB 3.0 for MANUAL(enable Manual_MSC)

 case CY_U3P_DMA_CB_PROD_EVENT:
            {
        		data_read_from_USB++;
			}

        break;
        case CY_U3P_DMA_CB_CONS_EVENT:
        {
        	data_written_to_SD++;
        }
        break;

 

Regards,
Rashi
0 Likes

Hello Rashi!

I modified the main project and pulled data out via HID since the UART board will take longer then expected. I can not share the full code for this.

For some annoying reason USB2 now doesn't work at all in manual, I will be trying with another device shortly but it's very strange, please see this for the full results and code modified:

https://docs.google.com/spreadsheets/d/1KnWocdWqCBSRdMvakhZjdhKDw-dKDmqDa4hU_5jq5Xw/edit?usp=sharing

I added 2 more global variables because I am going to investigate the other call backs between manual and auto_signal.

It would be helpful if you can answer my questions: Is there a way to encrypt data before it is sent to the mass storage in auto mode? What exactly does auto do that manual does not?

Regards!

Fujimi

0 Likes

Hello Rashi!

Additional info that might be interesting, this is a list of all the MSC's DMA call backs and the number of times they get called after the format operation is performed on USB3 in Auto_signal.

XFER_CPLT_OUT: 0000001a not handled
SEND_CPLT_OUT: 00000000 handled
RECV_CPLT_OUT: 000001ae handled
PROD_EVENT_OUT: 00000000 handled
CONS_EVENT_OUT: 0000007a not handled
ABORTED_OUT: 00000004 not handled
ERROR_OUT: 00000000 not handled
PROD_SUSP_OUT: 00000000 not handled
CONS_SUSP_OUT: 00000000 not handled
XFER_CPLT_IN: 0000005f not handled
SEND_CPLT_IN: 00000251 handled
RECV_CPLT_IN: 00000000 handled
PROD_EVENT_IN: 000000d1 handled
CONS_EVENT_IN: 00000000 not handled
ABORTED_IN: 00000004 not handled
ERROR_IN: 00000000 not handled
PROD_SUSP_IN: 00000000 not handled
CONS_SUSP_IN: 00000000 not handled

 

The "handled" is where there's code to do anything. I'm surprised to see that "aborted" comes up, and I will look into XFER_CPLT_OUT, XFER_CPLT_IN, CONS_EVENT_OUT further.

Regards!

Fujimi

0 Likes

 

Same table in manual mode, formatting in USB3 (before device completely freezes)

manual format after a few seconds  
XFER_CPLT_OUT: 00000005 not handled
SEND_CPLT_OUT: 00000000 handled
RECV_CPLT_OUT: 0000011b handled
PROD_EVENT_OUT: 00000027 handled
CONS_EVENT_OUT: 00000027 not handled
ABORTED_OUT: 00000007 not handled
ERROR_OUT: 00000000 not handled
PROD_SUSP_OUT: 00000000 not handled
CONS_SUSP_OUT: 00000000 not handled
XFER_CPLT_IN: 00000025 not handled
SEND_CPLT_IN: 000001a0 handled
RECV_CPLT_IN: 00000000 handled
PROD_EVENT_IN: 0000006c handled
CONS_EVENT_IN: 0000006c not handled
ABORTED_IN: 00000006 not handled
ERROR_IN: 00000000 not handled
PROD_SUSP_IN: 00000000 not handled
CONS_SUSP_IN: 00000000 not handled

This is interesting cause it also shows CY_U3P_DMA_CB_CONS_EVENT happens in manual but not auto, so I'm guessing it's from a retry host side.

Regards!

Fujimi

0 Likes

Hello Fujimi,

From the description, I understand that  the above values are captured after STEP 5  (Format) of the procedure mentioned in the sheet.  Is that correct?

From the code snippet shared in the sheet, I see that CyU3PDmaChannelCommitBuffer is called for CY_U3P_DMA_TYPE_AUTO_SIGNAL channel. CY_U3P_DMA_TYPE_AUTO_SIGNAL is same as the CY_U3P_DMA_TYPE_AUTO channel but it signals the events, CPU intervention is not expected for this channel. So, CyU3PDmaChannelCommitBuffer should not be called in the DMA callback when CY_U3P_DMA_TYPE_AUTO_SIGNAL/ CY_U3P_DMA_TYPE_AUTOis enabled. CyU3PDmaChannelCommitBuffer should only be called when CY_U3P_DMA_TYPE_MANUAL is used.

After the changes please let me know if read/write/format works fine with CY_U3P_DMA_TYPE_AUTO_SIGNAL channel

Also, it is strange that PROD_EVENT_OUT is 0 but we see CONS_EVENT_OUT and similarly for PROD_EVENT_IN and CONS_EVENT_IN for AUTO_SIGNAL channel . Is it possible for you to share the firmware as shared earlier? This will help to confirm  if the variables  mentioned in the table above are being tracked properly.

Also, can you please confirm if in the above tables xxxxx_IN events are for SIB > USB (glChHandleMscIn) channel and xxxxx_OUT events are for USB> SIB channel (glChHandleMscOut). If yes, for MANUAL channel the no. of events are less as compared to auto_signal channel.

Please let me know if you want me to share a  firmware with modification in default MSC firmware.

Regards,
Rashi
0 Likes

Hello Rashi!

Thanks for your response, to answer your questions:

"Please let me know if you are planning to encrypt the data inside FX3 using MANUAL channel"
Yes we planned on encrypting the data using manual, I am working on a work around solution where out channel is set to AUTO SIGNAL and in channel is MANUAL, this seems to resolve the issue we have, but it's not ideal as it requires handling the data after it has been written.

" I understand that  the above values are captured after STEP 5  (Format) of the procedure mentioned in the sheet.  Is that correct?"

Yes that is correct.

"After the changes please let me know if read/write/format works fine with CY_U3P_DMA_TYPE_AUTO_SIGNAL channel"

I corrected this but it actually didn't seem to effect anything, auto signal and auto work fine.

"Is it possible for you to share the firmware as shared earlier? This will help to confirm  if the variables  mentioned in the table above are being tracked properly."

I will need to move the changes over the sample MSC project since this was all migrated to our proprietary code (to make use of a custom HID channel for debug data output, the flashing method was just too painful....). Please give me some time to do so.

"Also, can you please confirm if in the above tables xxxxx_IN events are for SIB > USB (glChHandleMscIn) channel and xxxxx_OUT events are for USB> SIB channel (glChHandleMscOut). If yes, for MANUAL channel the no. of events are less as compared to auto_signal channel."

Yes the channels and direction are correct, but please note that during MANUAL channel, the operations fail, the auto_signal operation continues through the entire process, so larger values are expected.

Regards!

Fujimi

0 Likes

Hello Fujimi,

I am working on a work around solution where out channel is set to AUTO SIGNAL and in channel is MANUAL, this seems to resolve the issue we have, but it's not ideal as it requires handling the data after it has been written.

>> I understand that changing only the SIB > USB channel to MANUAL and changing USB > SIB channel to AUTO_SIGNAL works well with USB 2.0 and USB 3.0. Is that correct?

From the description, I understand that the data received from USB needs to be encrypted so only USB > SIB channel need to be changed to MANUAL. Is that correct?

If yes,  I can share the firmware by modifying the default MSC example. Also, can you check by changing only USB > SIB channel  to MANUAL in the current firmware for USB 3.0 and USB 2.0

Regards,
Rashi
0 Likes

Hello Fujimi,

Ahh... Isn't that Wewhat ModifiedFX3SMassStorage.zip is? In the first post that exhibits the issue?

>> We had made multiple modifications to the firmware that was shared earlier for the debug purpose. I will modify and share so that we can track variables required for debug.

Is there an example of using CyU3PSibVendorAccess with S-Port for data transfer?

>> We do not have a firmware implementing CyU3PSibVendorAccess API. You can refer to FX3 API guide for details on this API. Please include cyu3sibpp.h file.

The socket ID parameter can be  used as follows without any errors/warnings

CyU3PSibVendorAccess(0,CY_FX_MSC_SCSI_WRITE_10,8,8,&dataLength,5,CyTrue,CY_U3P_SIB_SOCKET0);

Please note the parameters passed to API except the last parameters are just for example. 

I don't understand the reason of using CyU3PSibVendorAccess API. This might make the debug confusing. We would recommend to check with the below mentioned configuration instead of using CyU3PSibVendorAccess.

Please help by responding to this from my previous response. this will help me to understand for which configuration is the failure seen and what is the requirement from the application.

"From the description, I understand that the data received from USB needs to be encrypted so only USB > SIB channel need to be changed to MANUAL. Is that correct?

I am working on a work around solution where out channel is set to AUTO SIGNAL and in channel is MANUAL, this seems to resolve the issue we have, but it's not ideal as it requires handling the data after it has been written.

>> From this it seems there is some problem in the USB > SIB channel and not the SIB > USB channel and also from the previous observations we have seen different behavior for USB 3.0 and USB 2.0 which also indicates that there is problem form USB > SIB interface. This can be confirmed by following configuration

USB > SIB channel : MANUAL

SIB > USB : AUTO_SIGNAL

Please check the above configuration for USB 3.0 and USB 2.0

Regards,
Rashi
0 Likes

Hello Fujimi,

Thank you for the details. I am checking them and will share my comments soon.

It would be helpful if you can answer my questions: Is there a way to encrypt data before it is sent to the mass storage in auto mode? What exactly does auto do that manual does not?

>> If the encrypted data is to be sent to FX3, it can be encrypted on the host application side.

Please let me know if you are planning to encrypt the data inside FX3 using MANUAL channel.

You can refer to section 3.7 of  Fx3 programmer's manual https://www.cypress.com/file/124386/download for difference between manual and auto channel.

In automatic DMA mode as soon as the DMA Producer socket buffer gets full it will be automatically committed to Consumer Socket without any CPU intervention. In manual mode, once the DMA buffer is filled by producer socket a CPU intervention is needed to commit the DMA buffer to Consumer socket. Please let me know if any queries on this.

Regards,
Rashi
0 Likes

Hello Rashi!

To answer this question: "If yes,  I can share the firmware by modifying the default MSC example. Also, can you check by changing only USB > SIB channel  to MANUAL in the current firmware for USB 3.0 and USB 2.0"
Ahh... Isn't that exactly what ModifiedFX3SMassStorage.zip is? In the first post that exhibits the issue?

"Please let me know if you are planning to encrypt the data inside FX3 using MANUAL channel."

Yes that is the desired approach.

The DMA documentation doesn't seem to explain why Manual with the commit operation callback does not work the same way as AUTO, so it seems like there is something else behind the scenes.

Regards!

Fujimi

0 Likes

Hello Rashi!

Is there an example of using CyU3PSibVendorAccess with S-Port for data transfer? I'm thinking of replacing write_10 and read_10. None of the examples I've seen so far uses it with S-Port so it's usage seems abit confusing, I'm guessing it will just perform a callback on the DMA channel connected to the socket?

I was also looking at the sib implementation in 1_3_4's src in the zip, specifically the files cyu3cardmgr_fx3s.c and cyu3sib_fx3s.c, how does SIB interaction happen? I tried to trace it but it's confusing with it's usage of things like "SIB->" where SIB is defined in some other file or header file. I'm thinking of handling some commands with jedec directly instead of using the wrappers provided, but the confusion is how to actually interact with the SIB through DMA channels that handle the connection....

Regards!

Fujimi

0 Likes

Ahhh to give an example of some of my confusion, socket in CyU3PSibVendorAccess is defined as a uint8_t, but the S-ports are: CY_U3P_SIB_SOCKET_0 = 0x0200, /**< S-port socket number 0. */ and greater, so I assume it's just stripped down to 0, 1, 2 etc. It's just not clear on how it's meant to be used.... An example would be greatly appreciated! Or a pseudo work flow process.

Right now I am pretty sure a write operation for a single block is something like:

  1. Select partition to operate on with switch
  2. Prepare data to send with CyU3PDmaChannelSetupSendBuffer
  3. Vendor access with CMD24 for a single block (512 bytes)

Since there is no output from a write that should be it? The read operation would use the DMA channels call back when finished?

Regards!

Fujimi

0 Likes

Hello Rashi!

I have got an FX3s with UART, whilst trying to get the output of the debug information, the FX3s does not seem to successfully start up when debug is outputted in callback for: CY_U3P_DMA_CB_RECV_CPLT under auto signal mode for DMA. Simply removing the debug makes it work... I have no clue why, perhaps it takes too long and makes the FX3s skip something?

I will gather all the information I can for you, but I might have to omit debug data from that, I can try making a delay for when to output debug?

Regards!

Fujimi

0 Likes

Hello Fujimi,

Please do not call CyU3PDebugPrint in the DMA callback. You can track the events triggering the DMA callbacks using global variable and print these variables in the for (;;) loop of CyFxMscAppHandleMscTask

Please let me know if this helps

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

Hello Rashi!

I've attached a version with UART debug output going to a global uint8_t array, the debug output file has allot of stuff in it.... I tried to make it readable but it's simply allot.

I noticed that I am getting "CyFxMscApplnSibCB_Fail", which is an error from: CyFxMscApplnSibCB in Manual mode when trying to format, you asked to check for this on May 17th but at the time I had no practical way to check for this. I'm not sure what is causing this error or how to get more data about it? I will start testing around it though.

Regards! Thank you for your fast responses!

Fujimi

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

The error in CyFxMscApplnSibCB is:

CY_U3P_ERROR_TIMEOUT
for event CY_U3P_SIB_EVENT_XFER_CPLT
Repeated 3 times, attached is code snippet for how that was retrieved.

Regards! I am very confused as to what would cause that, it seems like XFER CPLT also needs to be committed under certain circumstances?

Fujimi

0 Likes

Hello Fujimi,

Thank you for the debug prints

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

The UART traces before format are not same for AUTO and MANUAL, I understand that when Manual_MSC is disabled only the following event is registered and not all

dmaConfig.notification = CY_U3P_DMA_CB_SEND_CPLT

Please register for all the DMA events for AUTO case also (i.e. Manual_MSC  is disabled) and share the UART logs again. This will give more clarity between two scenarios

Regards,
Rashi
0 Likes