Complex GPIF configuration - test of the projects

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

cross mob
WGT_4383351
Level 5
Level 5
First like received

This thread is following the thread Complex GPIF configuration

To bring in meta-priority to the provided projects in that thread, another state is inserted:

SELECT_1_OR_2------LOGIC_ONE----------->STATE2

                             -----DMA_RDY_TH3|T2RDY------->RD_WR_IDLE_1

STATE2----- !DMA_RDY_TH1&!T0RDY------>SELECT_1_OR_2

               -----DMA_RDY_TH1|T0RDY------->RD_WR_IDLE

And flags are renamed:

FLAGA->T0RDY

FLAGB->T1RDY

FLAGC->T2RDY

FLAGD->T3RDY

T*RDY are just a name, doesn't mean it represents that thread of slave, the slave GPIF project is not modified at this stage.

This is the only modification, the firmware are not modified except rebuild for the new GPIF header.

Before this modification, all four channels work fine.

After this modification, slave EP2IN and master EP2IN can't receive (after master EP2OUT send or slave EP2OUT send)

Please test this modification on a standard AN87216 setup

pastedImage_1.png

0 Likes
1 Solution

Maybe two factor at the same time make the project dead:

1. Swtich beween Thread0/Thread1 and Thread2/Thread3 in slave GPIF and slave firmware

          As described in response 11. What is the reason?

2. I used EP3IN/OUT and use CY_U3P_UIB_SOCKET_PROD_3/CY_U3P_UIB_SOCKET_CONS_3 accordingly. I guess CY_U3P_UIB_SOCKET_PROD_3 doesn't mean EP3, but the 3rd ep in the project.

After changing to MT0-ST1/MT1-ST0/MT2-ST3/MT3-ST2 and use M-EP2OUT/S-EP2IN instead M-EP3OUT/S-EP3IN, the problems in the problematic project (based on AN87216, not your project) disappear.

View solution in original post

0 Likes
18 Replies
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Please share your complete GPIF Designer projects for master and slave so that I can evaluate the changes and understand the situation better.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

The reason may be indeed the STATE2 branch is always get selected over RD_WR_IDLE_1, then RD_WR_IDLE_1 branched will never be executed.

From the bellow GPIF header:

Left state of SELECT_1_OR_2  is STATE2, and right state is RD_WR_IDLE_1.

Since the condition to STATE2 is LOGIC_ONE, RD_WR_IDLE_1 will never be entered

So this problem is not very related to my problem (both branch can be entered) but another problem.

This return to a former problem: how to control which state is the left state during build of GPIF?

#define START 0

#define RD_WR_IDLE 2

#define WR_FLAG 3

#define WR_DATA 5

#define DR_ADDR 4

#define RD_CTRL 6

#define RD_CTRL1 7

#define DO_IN_DATA 8

#define DR_ADDR_1 9

#define SELECT_1_OR_2 1

#define RD_CTRL_1 11

#define RD_CTRL1_1 13

#define RD_WR_IDLE_1 10

#define DO_IN_DATA_1 14

#define WR_DATA_1 16

#define WR_FLAG_1 15

#define STATE2 12

CyU3PGpifWaveData CyFxGpifWavedata[]  = {

    {{0x1E711A01,0x0C00000C,0x80000000},{0x00000000,0x00000000,0x00000000}},

   {{0x6E709A0C,0x04000010,0x80000000},{0x5E151A0A,0x0D10000E,0x800000A0}},

    {{0x2E70DA03,0x044010C0,0xC0000000},{0x4E709A04,0x00880004,0x80000000}},

    {{0x5E729A05,0x04400000,0x80000040},{0x00000000,0x00000000,0x00000000}},

    {{0x2E10DA02,0x04001006,0x800000A0},{0x2E734406,0x00C00C00,0x80000000}},

    {{0x2E734407,0x00C00D00,0x80C00000},{0x00000000,0x00000000,0x00000000}},

    {{0x5E727A08,0x20C00000,0x80000010},{0x00000000,0x00000000,0x00000000}},

    {{0x5E151A0A,0x0D10000E,0x800000A0},{0x2E73480B,0x09C00C00,0x80000000}},

    {{0x4E711A09,0x09880004,0x80000000},{0x2E70BA0F,0x0D4010C0,0xC0000000}},

    {{0x2E73480D,0x09C00D00,0x80000000},{0x00000000,0x00000000,0x00000000}},

    {{0x2E10DA02,0x04001006,0x800000A0},{0x1E711A01,0x0C00000C,0x80000000}},

    {{0x5E727A0E,0x29C00000,0x80000010},{0x00000000,0x00000000,0x00000000}},

    {{0x5E729A10,0x0D400000,0x80000040},{0x00000000,0x00000000,0x00000000}}

};

0 Likes

I find out that I'v removed

            CyU3PGpifInitDataCounter(0,511,0,1,1);

            CyU3PGpifInitAddrCounter(0,511,0,1,1);

from the CyFxBulkLpApplnStart() in cyfxbulklpauto.c in master firmware.

These are not neede since they are taken care by GPIF state machine right?

0 Likes

Hello,

Firstly please let me know what exactly is the way in which the master and slave communicates with each other? Is it like the way in the project that was shared in the thread Complex GPIF configuration  ?

That is,

                    Thread0 of master communicates with thread 1 of slave

                    Thread1 of master communicates with thread 0 of slave

                    Thread2 of master communicates with thread 3 of slave

                    Thread3 of master communicates with thread 2 of slave

If not, then please let me know what is the sequence.

Regarding your question in your response 2, from the shared CyFxGpifWavedata structure, the state machine will go to STATE2 if both the transition equations are met.

Regarding your question in your response 4, yes if the state machine takes care of the counters, then you need not use it again in the firmware.

In addition to all these, please share the GPIF Designer project completely with all the modifications that you have made. This is essential as going forward I would need this to look inside the transition equations and the actions of each state.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

Quote from my question:

"

This is the only modification, the firmware are not modified except rebuild for the new GPIF header.

"

Forget my problematic project for now, what is discussed now is a clean start based on your project in that thread.

So

"

Is it like the way in the project that was shared in the thread Complex GPIF configuration  ?

"

Yes.

The only thing modifed now is new state added, as in the question.

"

the state machine will go to STATE2 if both the transition equations are met

"

This means the state machine will always goto STATE2, the branch RD_WR_IDLE_1 is dead. I'v asked about this problem before Re: GPIF thread arbitration , now it finnaly become a real problem - how to tell GPIF compiler which state should be the left state?

I thought the GPIF compiler will always put a LOGIC_ONE branch to right state to avoid dead branch, now it is clear there is no such feature.

0 Likes

A clean start based on your working project towards the problematic project is a better route than try to debug a problematic project.

0 Likes

I didn't mention that the two short packet states are removed too from the master GPIF project (besides the added state and links in the question), but this shouldn't matter.

0 Likes

Hello,

Please let me know why have you used the transition equations like this:

SELECT_1_OR_2------LOGIC_ONE----------->STATE2

                             -----DMA_RDY_TH3|T2RDY------->RD_WR_IDLE_1

From the discussions I understood that the left state of SELECT_1_OR_2 is STATE2 and the right state is RD_WR_IDLE_1. Also, from the transition equation, transition to STATE2 happens always. Also, if both are met, then the state machine will switch to left state which is again STATE2. As your understanding, this is the reason why the other state is not executed.

Now, the GPIF Designer generates the left and right state of a given state and we do not recommend to change this setting. So, you can try either of the following suggestions:

1.Make the transition equation to RD_WR_IDLE_1 as LOGIC_ONE and change the transition equation to STATE2 appropriately.

2. Use another state after SELECT_1_OR_2 (say state3). Let the transition equation from SELECT_1_OR_2 to state3 be LOGIC_ONE. The state3 will have two transitions one to RD_WR_IDLE with the transition equation being DMA_RDY_TH3|T2RDY. The other transition from state3 is to STATE2 with transition equation being !(DMA_RDY_TH3|T2RDY). The transition equation from STATE2 to state3 can be same as the transition equation that you are using now from STATE2 to SELECT_1_OR_2.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna

"Please let me know why have you used the transition equations like this:"

This is as your suggestion in response 32 in Complex GPIF configuration page 3. I put that added state in the right side, since the two left branches (A1=1) need to have higher priority than the right two branches.

Don't you think this is a must have feature of GPIF compiler?

1. Let the user specify which next state have higher priority

2. LOGIC_ONE next state always have lowest priority

0 Likes

Put the dead left branches problem away for now, at least the two branches on the right work now:

Thread0 of master communicates with thread 1 of slave

Thread1 of master communicates with thread 0 of slave

Here is a summary of the edits up to now as described above:

1. Two short packet states removed from master GPIF state machine

2. One state added to master state machine which make the two branches on the left dead

Now make a third edit:

In the slave state machine, from:

GPIO21 - Tread_1_DMA_RDY

GPIO23 - Tread_0_DMA_RDY

GPIO25 - Tread_3_DMA_RDY

GPIO22 - Tread_2_DMA_RDY

to:

GPIO21 - Tread_0_DMA_RDY

GPIO23 - Tread_1_DMA_RDY

GPIO25 - Tread_2_DMA_RDY

GPIO22 - Tread_3_DMA_RDY

and accordingly, in the slave firmware, in cyfxbulklpauto.h, from:

#define CY_FX_PRODUCER_PPORT_SOCKET    CY_U3P_PIB_SOCKET_0

#define CY_FX_CONSUMER_PPORT_SOCKET    CY_U3P_PIB_SOCKET_1

#define CY_FX_PRODUCER_PPORT_SOCKET1    CY_U3P_PIB_SOCKET_2

#define CY_FX_CONSUMER_PPORT_SOCKET1    CY_U3P_PIB_SOCKET_3

to:

#define CY_FX_CONSUMER_PPORT_SOCKET    CY_U3P_PIB_SOCKET_0

#define  CY_FX_PRODUCER_PPORT_SOCKET   CY_U3P_PIB_SOCKET_1

#define CY_FX_CONSUMER_PPORT_SOCKET1     CY_U3P_PIB_SOCKET_2

#define CY_FX_PRODUCER_PPORT_SOCKET1    CY_U3P_PIB_SOCKET_3

Now new problem appear:

slave EP1OUT to master EP1IN works fine.

master EP1OUT to slave EP1IN doesn't work now. In Control Center, master can send, slave won't receive. You can try this.

I guess even you only make the edit in this response to your project this problem will appear.

0 Likes

Can I switch a left state and right state in GPIF header directly?(I will do this each time it get compiled)

from:

{{0x6E709A0C,0x04000010,0x80000000},{0x5E151A0A,0x0D10000E,0x800000A0}},

to:

{{0x5E151A0A,0x0D10000E,0x800000A0},{0x6E709A0C,0x04000010,0x80000000}},

0 Likes

To response 9:

"

1.Make the transition equation to RD_WR_IDLE_1 as LOGIC_ONE and change the transition equation to STATE2 appropriately.

"

This doesn't work 1. This change the "priority" between left 2 branched and right 2 branched. 2. Also result in a state machine in which LOGIC_ONE is the left state

I'v tried with manually switch left and right states, this make the state machin dead.

0 Likes

"

2. Use another state after SELECT_1_OR_2 (say state3). Let the transition equation from SELECT_1_OR_2 to state3 be LOGIC_ONE. The state3 will have two transitions one to RD_WR_IDLE with the transition equation being DMA_RDY_TH1|T0RDY. The other transition from state3 is to STATE2 with transition equation being !(DMA_RDY_TH1T0RDY). The transition equation from STATE2 to state3 can be same as the transition equation that you are using now from STATE2 to SELECT_1_OR_2

"

This works (with typo fixed (bold) )

0 Likes

Maybe two factor at the same time make the project dead:

1. Swtich beween Thread0/Thread1 and Thread2/Thread3 in slave GPIF and slave firmware

          As described in response 11. What is the reason?

2. I used EP3IN/OUT and use CY_U3P_UIB_SOCKET_PROD_3/CY_U3P_UIB_SOCKET_CONS_3 accordingly. I guess CY_U3P_UIB_SOCKET_PROD_3 doesn't mean EP3, but the 3rd ep in the project.

After changing to MT0-ST1/MT1-ST0/MT2-ST3/MT3-ST2 and use M-EP2OUT/S-EP2IN instead M-EP3OUT/S-EP3IN, the problems in the problematic project (based on AN87216, not your project) disappear.

0 Likes

Hello,

Apologies for the delayed response.

Regarding your question in response 11, If my understanding is correct when data is sent to slave's OUT endpoint 1, it is transferred to the socket0 of slave FX3. The Master FX3 will read data from the socket 0 of the slave to the socket 0 of master FX3. Please let me know if my understanding is correct. Also, please let me know what is the data that you transferred from slave to master. Is the data all 0s? Or did you try sending non zero data from the slave and got the same data at master side?

Also, please let me know the list of ACTIONS in the states DO_IN_DATA and WR_DATA.

Regarding your doubt in response 15, the CY_U3P_UIB_SOCKET_PROD_3 is the socket for the OUT endpoint 3 (0x03) and CY_U3P_UIB_SOCKET_CONS_3 is the socket for IN endpoint 3 (0x83).

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

As in response 15, the problem is solved, the remaining question is just for curious, if you are busy you can suspend this thread for now.

"

Also, please let me know what is the data that you transferred from slave to master. Is the data all 0s? Or did you try sending non zero data from the slave and got the same data at master side?

"

All zero.

"

please let me know the list of ACTIONS in the states DO_IN_DATA and WR_DATA

"

Please follow the edits I mentioned in the thread and try it on AN87216 setup, there is only very few edits from your project.

0 Likes

Hello,

I do not have the setup for testing this project now. Please take my suggestions and test this on your end and let me know the result.

Please try sending non zero data from slave through OUT endpoint 1 and let me know if you are getting the same data at the master side. This test need to be done on the project that you were describing in your response 11 and not response 15. The master selects a particular thread of the slave by driving the pins A1 and A0,so when you are changing the threads in the slave project, you should also take care that these signals are properly driven from the master state machine.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
WGT_4383351
Level 5
Level 5
First like received

The goal of this thread: I will modify the projects in Complex GPIF configuration  step by step toward the problematic setup to find out which factor result in the problems.

0 Likes