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

USB superspeed peripherals Forum Discussions

inal_2949331
Level 3
Level 3
5 likes given First like given Welcome!

Hi everyone!

Unfortunately this topic was locked.

I need to control data integrity of FX3 GPIF bus in PP mode. There is some CRC engine, but it is not documented at all.

I tried to make it work and I have some successful results:

I can configure this CRC over GPIF_CRC_CONFIG and GPIF_CRC_DATA regs.

First set ENABLE = 1 (bit 31) of GPIF_CRC_CONFIG and INITIAL_VALUE[15:0] = 0xFFFF of GPIF_CRC_DATA reg.

Manually changing bits in GPIF FSM configuration I could make it work in write direction (from FX3 to AP).

I used BETA_INIT_CRC bit to reset init value to previously defined INITIAL_VALUE[15:0] and BETA_CALC_CRC to make calculation.

Calculated CRC appears in CRC_VALUE[15:0]  of GPIF_CRC_DATA reg.

I figured out that "CRC-16/CCITT-FALSE" with params poly = 0x1021 is used in hardware.

QUESTION: I run GPIF in 32-bit mode, but that CRC16 does not use higher 16 bits of bus during calculation. In other words only lower 16-bits

are CRC controlled. How to make it work in 32-bit mode, not 16-bit? What am I doing wrong?

P.S. I don't need working example, just explain it here please. I need it very much. Thank you!

Best regards

0 Likes
32 Replies
inal_2949331
Level 3
Level 3
5 likes given First like given Welcome!

Following EZ-USB® FX3™ Technical Reference Manual document at page 358 one can find:

BYTE_ENDIAN - Indicates the order in which bytes in a 32-bit word are brought through the CRC shift register. This is independent from the endianness of the interface.

Looks like CRC engine works with 32-bit words.

I guess your engineers have HDL sources that can reveal the way this CRC works. That shouldn't be a problem for you to answer my question.

Thanks in advance

0 Likes
Keerthy
Moderator
Moderator
Moderator
50 solutions authored 25 solutions authored 10 solutions authored

The CRC calculation is controlled by betas. On beta initialize_crc (CYU3GPIF_BETA_INIT_CRC), the CRC is initialized to the value programmed in GPIF_CRC_DATA.INITIAL_VALUE. The CRC is calculated when beta calculate_crc (CYU3GPIF_BETA_CALC_CRC)is set and read (CYU3GPIF_BETA_POP_RQ ) or write (CYU3GPIF_BETA_PUSH_WQ) is done. The calculated CRC is reflected in GPIF_CRC_DATA.CRC_VALUE.

  • The calculated CRC is transmitted when beta use_crc (CYU3GPIF_BETA_USE_CRC) is set and alpha update_dout (CYU3GPIF_ALPHA_UPD_DOUT) is asserted.
  • The incoming CRC is sampled when beta use_crc (CYU3GPIF_BETA_USE_CRC) is set and beta wq_push (CYU3GPIF_BETA_PUSH_WQ) is asserted.

Hi, KeerthyV_76

This is incredibly useful information!

I'm going to try make it work according to your explanations.

Thank you!

P.S. Please don't lock this topic for a while. I will mark right anwer as soon as possible.

0 Likes

Hi, KeerthyV_76

It seems to be not so easy, as I supposed.

On beta initialize_crc (CYU3GPIF_BETA_INIT_CRC), the CRC is initialized to the value programmed in GPIF_CRC_DATA.INITIAL_VALUE.

Initialization works fine.

The CRC is calculated when beta calculate_crc (CYU3GPIF_BETA_CALC_CRC) is set and read (CYU3GPIF_BETA_POP_RQ ) or write (CYU3GPIF_BETA_PUSH_WQ) is done. The calculated CRC is reflected in GPIF_CRC_DATA.CRC_VALUE.

I can see that GPIF_CRC_DATA.CRC_VALUE changes on write, but I can't do the same for the read. It doesn't calculate it for read. Maybe some GPIF configuration registers are not set properly? I tried to set DOUT_POP_EN = 0 to drive it manually over beta, but nothing changes.

  • The calculated CRC is transmitted when beta use_crc (CYU3GPIF_BETA_USE_CRC) is set and alpha update_dout (CYU3GPIF_ALPHA_UPD_DOUT) is asserted.

As I understand I should receive CRC value from FX3 over data bus. For a test I tried to read mailbox register, set use_crc beta with update_dout alpha and expected to receive checksum, but it doesn't happen.

  • The incoming CRC is sampled when beta use_crc (CYU3GPIF_BETA_USE_CRC) is set and beta wq_push (CYU3GPIF_BETA_PUSH_WQ) is asserted.

I also tried to send CRC to get GPIF_CRC_CONFIG.CRC_RECEIVED changed, but it remains zero.

P.S. GPIF is quite complex, could you please send some more information about it? Maybe some waveforms or even HDL simulation? Any additional information will help.

Best regards

0 Likes

Hi

Unfortunately I really need to get this CRC work.

Will be grateful for the help.

Thanks in advance

0 Likes
Keerthy
Moderator
Moderator
Moderator
50 solutions authored 25 solutions authored 10 solutions authored

Hi,

Can you please provide the complete state machine and timing diagram (by probing the lines using scope)?

We will analyze the same and will provide you an update.

Regards,

Keerthy

0 Likes

Hi,

Sorry for delay, now I'm ready for real time communication.

I have developed an extremely simple test project for different experiments.

There are several things, that are not clear for me. But for simplicity let me ask more concrete questions to solve this problem step by step. So we have a simple project (no USB logic). In current project I configure AP to receive 32 bytes over mailbox and send 32 bytes from CPU to AP over manual dma. At this step I want to see expected CRC16 of sent 32 data bytes in GPIF_CRC_DATA.CRC_VALUE (0xE0014128) register.

Here is GPIF state machine configuration with my patches for CRC calculation:

- GPIF_CRC_DATA.CRC_VALUE register is initialized in GPIF state INIT_CRC by pulling CYU3GPIF_BETA_INIT_CRC.

- CYU3GPIF_BETA_CALC_CRC is pulled in states ADDR and READ for calculation of outgoing data.

test_crc_init+calc.png

After successful transfer I can see GPIF_CRC_DATA.CRC_VALUE = 0xFB97.

crc_value.png

Actually see: CRC-16/CCITT-FALSE (0x1000, 0x1001, 0x1002, 0x1003, 0x1004, 0x1005, 0x1006, 0x1007) = 0xFB97

Expected to see: CRC-16/CCITT-FALSE (0xC0DE1000, 0xC0DE1001, 0xC0DE1002, 0xC0DE1003, 0xC0DE1004, 0xC0DE1005, 0xC0DE1006, 0xC0DE1007) = 0x5C66

Test project and .VCD waveforms are attached.

QUESTION: I run GPIF in 32-bit mode, but that CRC16 does not use higher 16 bits of data bus during calculation. How to make it work in 32-bit mode, not 16-bit?

Regards

0 Likes

Up

0 Likes

Hi

I'm running out of ideas how to make it work properly. Really need support.

Thanks in advance

0 Likes

Hi

Still need support.

Regards

0 Likes

Hi

Sorry, is there any change to get support for my case? Is this forum the only way to get support from Cypress?

I'm sure one need ~20min to find out the way this CRC works having all development sources.

Thanks

0 Likes

Up

0 Likes

Up

0 Likes

Up

0 Likes

Up.

0 Likes

Up

FX2LP had even ECC engine on GPIF bus. In case of FX3 CRC feature is even more mandatory.

0 Likes

Up

0 Likes

Up

0 Likes

UP!

0 Likes

UP!

0 Likes

Up

0 Likes

Up and up again.

0 Likes

Cypress, you are selling FX3 for about 10 years and has no idea the way it works? This is ridiculous! I'm sure there were engineers who invented, developed, simulated and tested FX3's architecture. How could this CRC engine appear in FX3 without any documentation?!

I would understand if you say something like: "We had planes to add CRC to GPIF, but refused from this idea. Though you can find something about it in documentation - this a mistake. It is not implemented in silicon". But I see that it works somehow! It is implemented in silicon, but I can't use it fully due to a very poor documentation!

I really need support from design team.

Regards

0 Likes

Unfortunatelly I have to bring this topic up again because I can't contact support team. Still need support.

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

Please go through the attachment.

I have provided my test details.

Regards,

Hemanth

Hemanth
0 Likes

Hi,

I saw you attachment and also replied it, looks like you haven't receive my email.

I will copy it here, please go through the attachment.

Regards

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

I am able to get the CRC value 0xFB97. I will update you further.

Regards,

Hemanth

Hemanth
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Aldo,

I had contacted FX3 Designers who got back to me after checking the CRC implementation details. Unfortunately we found that the input for CRC engine is only 16-bit word and hence works only for 16-bit data input/output. It cannot be used for 32-bit data.

So, in your application, can you consider implementing 16-bit GPIF interface instead of 32-bit? If 32-bit interface is mandatory can you consider software implementation of CRC calculation?

Regards,

Hemanth

Hemanth

Hi, Hemanth

I had contacted FX3 Designers who got back to me after checking the CRC implementation details. Unfortunately we found that the input for CRC engine is only 16-bit word and hence works only for 16-bit data input/output. It cannot be used for 32-bit data.

So, in your application, can you consider implementing 16-bit GPIF interface instead of 32-bit? If 32-bit interface is mandatory can you consider software implementation of CRC calculation?

Pitty to hear that, but any way I hope we can consider using 16-bit GPIF interface instead of 32-bit.

Now to start using this CRC engine we should know the way how to send and receive calculated CRC value over GPIF bus. There is some tricky manipulation of beta signals. I tried to follow Keerthy's explanation, but that didn't work:

  • The calculated CRC is transmitted when beta use_crc (CYU3GPIF_BETA_USE_CRC) is set and alpha update_dout (CYU3GPIF_ALPHA_UPD_DOUT) is asserted.
  • The incoming CRC is sampled when beta use_crc (CYU3GPIF_BETA_USE_CRC) is set and beta wq_push (CYU3GPIF_BETA_PUSH_WQ) is asserted.

Follow my message: https://community.cypress.com/message/185948#185948

I hope that FX3 Designers can provide full instruction of using GPIF beta signals for CRC.

Best regards,

Aldo

0 Likes

Up.

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Aldo,

Please find the attached projects.

USBMassStorageDemo (which was shared by you initially) is modified.

To drive the above project's state machine, as mentioned in my previous posts, I have used another FX3, whose project (GpifToUsb) is also attached.

The images show the data driven (on 16 data lines D0-D15) and the CRC transmitted out at the end.

Referring to the state machine in the path: crc_for_8_16_bit_words\USBMassStorageDemo\gpif_admux.cydsn:

1. CRC is transmitted out when the transition happens from STATE9 to STATE10

2. For the above to happen:

    a. ALPHA_UPD_DOUT, ALPHA_DQ_OEN and BETA_USE_CRC is asserted in state - 'READ'

    b. BETA_USE_CRC is asserted in STATE8

3. Only 7 16-bit words are transmitted in state - 'READ'

4. The last 16-bit word (in this example 0x1007) is sent out in STATE8

Note:

1. Even though I did not change the bus width in the state machine from 32 to 16, you know that the upper 16 bits will be ignored for the CRC calculation.

2. To transmit the CRC of N words out: N-1 words are driven in state X, then transition to state X+1 to drive the last word and then lastly CRC is driven when transition happens from state X+2 (as explained above)

3. I have added DebugPrints in your project to print out the CRC value read from the register (whose log is attached)

Regards,

Hemanth

Hemanth
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Aldo,

I have one more update. This is regarding FX3 reading the CRC sent over GPIF and validating using calculated CRC.

Please find the attached project files: GpifToUsb example which provides the necessary signals for the state machine in the Project USBMassStorageDemo.

Due to the setup issues, I have validated only the false test case which is as follows:

DQ0 line is pulled high permanently so that FX3 samples 0x0001 always. So, the state machine in the Project USBMassStorageDemo would be sampling 7 16-bit words of 0x0001, followed by the CRC which is also 0x0001 (This would be reflected in bits 0: 15 of GPIF_CRC_CONFIG register).

Correct CRC value for 7 16-bit words of 0x0001 is 0xEA42. So bit 22 (CRC_ERROR) of GPIF_CRC_CONFIG should be set.

Referring to the cyfxgpif2config.h file of USBMassStorageDemo Project:

Beta USE_CRC and Beta PUSH_WQ are asserted in STATE6, which will take effect when the state machine is in STATE8.

Regards,

Hemanth

Hemanth