Behavior of standalone DMA_RDY_TH* event

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

cross mob
KaFu_3122371
Level 1
Level 1
First like given 10 sign-ins 5 questions asked

I would like confirmation of the behavior of a standalone DMA_RDY_TH* event within the transition equation of a GPIF II state machine. What I mean is that when the from and to states of the DMA_RDY_TH* event does not have any actions, what is the behavior of this event? I ask because after looking through the documentations, especially "7.11 GPIF II State Machine to Read Data into a Socket" in the FX3 technical reference manual where it gives the clearest example of this event, I cannot find anything relating to using this event without any corresponding IN_DATA or DR_DATA action.

For reference, below is the GPIF II state machine and associated DMA channel configuration.

From my own testing, the DMA_RDY_TH0 and DMA_RDY_TH1 are LOW when both DMA buffers of the corresponding producer socket are filled, wrapped up, and committed to the USB consumer. They are HIGH when at least one buffer of the corresponding producer socket is empty and ready to read in data from the PPort data bus. Is my understanding correct? Or is the usage of these events invalid here even though the GPIF II Designer gave no errors or warnings?

pastedImage_0.png

CyU3PMemSet((uint8_t *)&dmaMultiConfig, 0, sizeof(dmaMultiConfig));

dmaMultiConfig.size           = DMA_BUFFER_SIZE;

dmaMultiConfig.count          = DMA_BUFFER_COUNT;

dmaMultiConfig.validSckCount  = 2;

dmaMultiConfig.prodSckId[0]   = (CyU3PDmaSocketId_t)PING_PRODUCER_SOCKET;     // CY_U3P_PIB_SOCKET_0

dmaMultiConfig.prodSckId[1]   = (CyU3PDmaSocketId_t)PONG_PRODUCER_SOCKET;     // CY_U3P_PIB_SOCKET_1

dmaMultiConfig.consSckId[0]   = (CyU3PDmaSocketId_t)CY_FX_EP_CONSUMER_SOCKET; // CY_U3P_UIB_SOCKET_CONS_1

dmaMultiConfig.prodAvailCount = 0;

dmaMultiConfig.prodHeader        = 0;

dmaMultiConfig.prodFooter        = 0;

dmaMultiConfig.consHeader        = 0;

dmaMultiConfig.dmaMode        = CY_U3P_DMA_MODE_BYTE;

Status = CyU3PDmaMultiChannelCreate(&glDualGPIF2USB_Handle, CY_U3P_DMA_TYPE_AUTO_MANY_TO_ONE, &dmaMultiConfig);

Thank you

0 Likes
1 Solution
YashwantK_46
Moderator
Moderator
Moderator
100 solutions authored 50 solutions authored 50 likes received

Hello,

"the DMA_RDY_TH0 and DMA_RDY_TH1 are LOW when both DMA buffers of the corresponding producer socket are filled, wrapped up, and committed to the USB consumer. They are HIGH when at least one buffer of the corresponding producer socket is empty and ready to read in data from the PPort data bus. Is my understanding correct?"

=> Yes, your understanding is correct.

Also, can you let me know why you are transitioning from [WAIT_4_FW_TRIG] => FW_TRG => [WAIT_4_BUFFER0] => DMA_RDY_TH0 => [WAIT_4_BUFFER1] => DMA_RDY_TH1 => [WAIT_4_LINEEND]......

Are you waiting on empty buffers from both the threads?
If not, you can use a state [WAIT_4_FW_TRIG] => FW_TRG => [WAIT_4_BUFFER] => DMA_RDY_TH0 | DMA_RDY_TH1 => [WAIT_4_LINEEND]......

Regards,

Yashwant

View solution in original post

0 Likes
3 Replies
YashwantK_46
Moderator
Moderator
Moderator
100 solutions authored 50 solutions authored 50 likes received

Hello,

"the DMA_RDY_TH0 and DMA_RDY_TH1 are LOW when both DMA buffers of the corresponding producer socket are filled, wrapped up, and committed to the USB consumer. They are HIGH when at least one buffer of the corresponding producer socket is empty and ready to read in data from the PPort data bus. Is my understanding correct?"

=> Yes, your understanding is correct.

Also, can you let me know why you are transitioning from [WAIT_4_FW_TRIG] => FW_TRG => [WAIT_4_BUFFER0] => DMA_RDY_TH0 => [WAIT_4_BUFFER1] => DMA_RDY_TH1 => [WAIT_4_LINEEND]......

Are you waiting on empty buffers from both the threads?
If not, you can use a state [WAIT_4_FW_TRIG] => FW_TRG => [WAIT_4_BUFFER] => DMA_RDY_TH0 | DMA_RDY_TH1 => [WAIT_4_LINEEND]......

Regards,

Yashwant

0 Likes

Hi Yashwant,

Yes, I want to make sure that there is at least one buffer available for each producer socket before beginning. Is there a better way to ensure that without using the DMA flags to the application processor? I want this handled entirely on the FX3 side.

"If not, you can use a state [WAIT_4_FW_TRIG] => FW_TRG => [WAIT_4_BUFFER] => DMA_RDY_TH0 | DMA_RDY_TH1 => [WAIT_4_LINEEND]......"

=->As an aside, the GPIF II designer would not let me do DMA_RDY_TH0 | DMA_RDY_TH1. They "cannot be used together in the outgoing equations...". I still feel like this is an incorrect usage of these events because of error messages when trying things like this, and because all examples of these events are always tied to going to or from a state with a IN/DR_Data action.

And for bonus, is there a way to ensure that ALL buffers I assigned to this channel are empty and available on the producer list?

Thanks,

Dave

0 Likes

Hi Dave,

"Is there a better way to ensure that without using the DMA flags to the application processor?"

=> The current implementation is a good way to ensure both the threads have at least one available empty buffer.

"As an aside, the GPIF II designer would not let me do DMA_RDY_TH0 | DMA_RDY_TH1. They "cannot be used together in the outgoing equations...". I still feel like this is an incorrect usage of these events because of error messages when trying things like this, and because all examples of these events are always tied to going to or from a state with a IN/DR_Data action."

=> Apologies about that. I realized that there are restrictions in the GPIF designer to use DMA_RDY_TH0 and DMA_RDY_TH1 on the same transition equation and can't be done.

The current implementation will suffice for the application needs.

"And for bonus, is there a way to ensure that ALL buffers I assigned to this channel are empty and available on the producer list?"

=> All of the buffers are not available because of the ping-pong (recycling) mechanism of buffers being used inside FX3 to facilitate the un-interrupted data transmission from the P-port to the U-port and vice versa.

Regards,
Yashwant

0 Likes