The work-around for the RP2040 DATA Sequence error bug is temporary

[rppicomidi]

I think maybe you asked for a comment on this code in the discussion of hathach/tinyusb#2814 in light of the pull request.

Checking for each and every known VID/PID combo that ships with an initial data sequence error is hard to maintain and does not fix noisy environment data sequence errors. The code here references an early TinyUSB issue and the proposed workaround here:

    // NOTE: There is a significant bug in the rp2040 hardware, shown at:
    //
    //       https://github.com/hathach/tinyusb/issues/2776
    //
    // As a temporary workaround, we can override the default starting data_pid
    // to begin with a 1 instead of the correct value, which should be a 0.

You are better off having a look at hathach/tinyusb#2814. Basically, you start an Interrupt transfer on epx instead of a bulk transfer because bulk transfers will retry NAK forever. If you get a NAK, you check to see if the data sequence error bit is set, fix it as you do in this code, then retry the transaction. The downside to handling all this is you wind up having to handle the SOF interrupt because proper bulk transfers do not auto-retry NAK'd transactions when you tell epx they are interrupt transfers. The upside of handling the SOF interrupt is now you have a timing source to implement interrupt transfers, too. That is what hathach/tinyusb#2814 implements.

I hope this is the sort of response you were looking for in the pull-request discussion. If not, please close this issue.

[shreeve]

Great comments. I will look at hathach/tinyusb#2814 and get that implemented. Thank you!

[rppicomidi]

@shreeve If you want a quick walk through the pull request code, search the code in the pull request for Scheduling Algorithm. There is a comment that attempts to explain what is going on. Also have a look at 'hcd_rp2040_irq' code. That should help too. Good luck.

[shreeve]

@rppicomidi - perfect, I’ll take a look at it now

…

On Wed, Nov 13, 2024 at 3:34 PM rppicomidi ***@***.***> wrote: @shreeve <https://github.com/shreeve> If you want a quick walk through the pull request code, search the code in the pull request for Scheduling Algorithm. There is a comment that attempts to explain what is going on. Also have a look at 'hcd_rp2040_irq' code. That should help too. Good luck. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABC4GYHYPSPWUEQGF5FIDD2APHYPAVCNFSM6AAAAABRVJFBR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUHE2TSOJUHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[shreeve]

@rppicomidi - Very helpful to read your comments in the "Scheduling Algorithm" section. Why do you use the NAK interrupt, if it means that the device is not ready with any data?

[rppicomidi]

When the device responds NAK, the algorithm can schedule a different transaction. The driver configures EPx for interrupt endpoint mode for both bulk transfers and interrupt transfers. The reason is that bulk transfers will retry until complete on EPx but interrupt transfers try only once. The retry until complete behavior does not work if the code is waiting for asychronous IN traffic whist also sending asychronous OUT traffic. So the scheduler tries an IN transfer. The device responds NAK. Then in the same frame (if there is still time), the scheduler can try a pending OUT transaction. If that responds NAK, the scheduler can try yet a different transfer. Etc.

Does that make sense?