odd/even bit in assynchronous

[g_gulbinas]

Posted on September 03, 2016 at 15:32

Help me someone pls a little bit. I don't understand why in most isochronous assynchronous transfer with feedback examples they call feedback transfer function in SOF callback with frame odd/even setting being for the next frame. In't SOF being executed first in the frame and then host sends IN request for feedback data? Shouldn't frame odd/even bits be set for current frame or be done at the end of the frame after GINTSTS.EOPF / OTG_FS_GINTSTS.IISOIXFR interrupt?

#usb #asynchronous #audio #!stm32-!usb

[g_gulbinas]

Posted on September 03, 2016 at 16:15 Is this site dead? Don't wanna look like a whiny little bi**h, but if its not much happening here i would like to know. Or is is just me, bad formatting, unclear question, etc.

[Tesla DeLorean]

Posted on September 03, 2016 at 16:34

Is this site dead?

Expecting a response in 45 mins is probably unrealistic. This is a user forum, full of people just like you, so assume most can't even answer their own questions, and rarely answer others with useful responses. The subset of users here who can provide answers is small, and I don't answer questions which don't touch within my area of expertise or experience, or can't be addressed with basic problem solving techniques.

[g_gulbinas]

Posted on September 03, 2016 at 17:06

[g_gulbinas]

Posted on September 03, 2016 at 17:49

Hello, Tsuneo.

In your (2) point you are saying that firmware has time to get ready to send feedback, which is ''sort of'' done in most of examples i have seen

static uint8_t usbd_audio_SOF (void *pdev)
{ 
...
DCD_EP_Tx (pdev, AUDIO_IN_EP, (uint8_t *) &feedback_data, 3);
...
return USBD_OK;
}

My problem is that function DCD_EP_Tx() is standard library function and besides other things it sets odd/even frame bit for the following frame

... 
if (ep->type == EP_TYPE_ISOC)
{
dsts.d32 = USB_OTG_READ_REG32(&pdev->regs.DREGS->DSTS);
if (((dsts.b.soffn)&0x1) == 0)
{
depctl.b.setd1pid = 1;
}
else
{
depctl.b.setd0pid = 1;
}
}
/* EP enable, IN data in FIFO */
depctl.b.cnak = 1;
depctl.b.epena = 1;
USB_OTG_WRITE_REG32(&pdev->regs.INEP_REGS[ep->num]->DIEPCTL, depctl.d32);
...

[tsuneo]

Posted on September 03, 2016 at 19:57

I've reviewed my stored USB traces, and noticed that above 2) is not always true.

- MacOSX puts the transactions in above order, OUT / IN - Windows issue IN first, OUT follows.> My problem  is that function DCD_EP_Tx() is standard library function and besides other things it sets odd/even frame bit for the following frame It is unknown when the host would start the isoc IN transaction. - in my trace log, Mac: 13 frames after Set_Interface(alt:1), Windows: 11 frames Your firmware should prime the IN EP (ie. DCD_EP_Tx() call) at every frame. As mentioned in 3), host doesn't put isoc IN transaction at every frame. When your firmware primes the IN EP in every frame, - if the host puts an IN transaction at the next frame, XFRC (transfer complete) interrupt occurs at the end of the transaction. - if the host doesn't put any IN transaction at the frame, ISOIXFR (Incomplete isochronous IN transfer) flag should up at the timing of EOPF (end of periodic frame interrupt). After all, simple implementation is, At the EOPF interrupt, - if ISOIXFR occurs, the IN EP is disabled (SNAK/EPDIS) once, and re-enabled The IN EP is primed for the next frame in this interrupt. Tsuneo

[g_gulbinas]

Posted on October 21, 2016 at 03:11

Hi again,

i still can't make host understand or see my feedback, which is very weird and depressing, because i don't find anyone having that kind of problem. Besides odd/even bits, which i tried to switch already. I'm not sure if thats host misentepreting something, if its me failing writing to TxFIFO somehow or something else. Here are a couple of clues :

• I can see host issuing Isoch Transfer request the endpoint, but failing to receive answer. I get URB status USBD_STATUS_ISOCH_REQUEST_FAILED, with error status 0xC000000E, which is not in the table listed in ( https://msdn.microsoft.com/en-us/library/windows/hardware/ff539136(v=vs.85).aspx). Then host resets pipe and tries again.

• I can't confirm feedback data is properly written to txfifo, because reading from that location doesn't give me anything. I write data to fifo, core decrements xfrsiz properly, but but pktcnt is not decremented, so no XFRC interrupt. My piece of code to work feedback trasnsfer:

uint32_t DCD_EndOfFrame_ISR(USB_OTG_CORE_HANDLE *pdev)
{
USB_OTG_GINTSTS_TypeDef gintsts; 
USB_OTG_DSTS_TypeDef FS_DSTS;
feedbackBuff [0] = 0; 
feedbackBuff [1] = 0;
feedbackBuff [2] = 0x0c;
FeedbackFlagMine++;
gintsts.d32 = USB_OTG_READ_REG32(& ((USB_OTG_CORE_HANDLE*)pdev)->regs.GREGS->GINTSTS));
if(gintsts.b.incomplisoin)
{
USB_OTG_MODIFY_REG32(0x50000940,0x00,0x8000000); //snak
while(!((USB_OTG_READ_REG32(0x50000948) >> 6) & 0x01));// while nak has taken effect
USB_OTG_MODIFY_REG32(0x50000940,0x00,0x48000000);// snak/epdis to disable endpoint
while(!((USB_OTG_READ_REG32(0x50000948) >> 1) & 0x01)); // wait for core to disable endp
DCD_EP_Flush (pdev , AUDIO_IN_EP);
DCD_EP_Tx (pdev,
AUDIO_IN_EP,
(uint8_t*)feedbackPtr, 
AUDIO_IN_PACKET);
FeedbackFlagMine = 0;
gintsts.b.incomplisoin = 1;
USB_OTG_WRITE_REG32(&pdev->regs.GREGS->GINTSTS, gintsts.d32);
}
if((FeedbackFlagMine >= 2)&&(TransmStarted > 0))
{
DCD_EP_Tx (pdev,
AUDIO_IN_EP,
(uint8_t*)feedbackPtr, 
AUDIO_IN_PACKET);
FeedbackFlagMine = 0;
}
gintsts.b.eopframe = 1;
USB_OTG_WRITE_REG32(&pdev->regs.GREGS->GINTSTS, gintsts.d32);
return 1;
}

Here IISOIXFRM is disabled and EOPFM is enabled in GINTMSK register. Is there any way to confirm that my data has been properly written to TxFIFO? Any clue where would be very useful.

[jmf1]

Posted on October 21, 2016 at 07:33

Hi,

I'm a bit in a hurry, so I apologized for being short and not having read everything. I struggled with that and arrived to someting working here: https://github.com/jmf13/USB_Async_DAC/tree/CleanerCode I tried to collect my experience with this here: https://github.com/jmf13/Const_DSP_I2S_DAC/wiki And especially here: https://github.com/jmf13/Const_DSP_I2S_DAC/wiki/Async-USB-inspiration The thread that helped me understand the point and the specificity of the Stm32 for feedback is this one: http://www.chibios.com/forum/viewtopic.php?f=16&t=926 Sorry if it doesn't help. JMF

[ColdWeather]

Posted on October 21, 2016 at 10:05

Using the ST FS USB Library applied to my F103, I provide the feedback data to the host in the IN interrupt of the feedback endpoint taking no care about any odd/even issues: when the host needs the data, it sends an IN request, the interrupt is triggered, that copies the data to the IN buffer and sets RX ready.

[g_gulbinas]

Posted on October 21, 2016 at 13:24

Ty guys, i'll try to make it work today.