Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USB3 Super Speed implement USB CDC #17

Open
bvernoux opened this issue Oct 2, 2022 · 8 comments
Open

USB3 Super Speed implement USB CDC #17

bvernoux opened this issue Oct 2, 2022 · 8 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@bvernoux
Copy link
Member

bvernoux commented Oct 2, 2022

USB3 Super Speed implement USB CDC with an example (will need to update the https://github.com/hydrausb3/wch-ch56x-bsp)

  • To be checked on the feasibility and performance with compliance with CDC/ACM (USB Serial Device)
  • To implement fallback to USB 2 High Speed
@bvernoux bvernoux added the help wanted Extra attention is needed label Oct 2, 2022
@bvernoux bvernoux added the enhancement New feature or request label Apr 9, 2023
@bm16ton
Copy link

bm16ton commented Jun 12, 2023

After realizing I couldn't find any working stm32 usbhs 2 cdc (either builtin like stm32f723 or adding ulpi to f4 f7 h7) I took the time to write a working implantation this week on my portenta h7 via libopencm3, its still the only one I'm aware of that works. The stlinkv3 was recently added to blackmagic probe fingers crossed they work on fixing its usb2uart. So I received my hydrausb boards yesterday and today I find this post. Guess maybe I could spend sum more time on usb 2 cdc on faster interfaces for a bit. I assume I can find an english reference manual/datasheet on one of these repos. I'm curious what interrupts ill have to use, something akin to uart's idle and dma's tx complete would be ideal. I've never had anything with usb3 I could play with so ill hafta read that spec as well. USB2HS had the "strict" 512 bulk endpoints packet size I assume usb3 will have even higher, and I guess if they changed what the binterval represents for a time measurement again ill need to know, maybe just those 2 things will hopefully be enuff to get me on my feet. If you forsee any curve balls I might be overlooking pls let me know. Have you started any work on this that is/or can be posted somewhere? Great work, great product, As always I appreciate your contributions to the opensource hardware/software scene.
hrm just realized usb3 was closed blob driver so doubtfull all its registers are in official docs, I assume you must have documented your code etc and also maybe all the registers? and all possible options for them? Ha I'm not asking for much huh? Alright I'm off to get docs

@bvernoux
Copy link
Member Author

bvernoux commented Jun 13, 2023

After realizing I couldn't find any working stm32 usbhs 2 cdc (either builtin like stm32f723 or adding ulpi to f4 f7 h7) I took the time to write a working implantation this week on my portenta h7 via libopencm3, its still the only one I'm aware of that works. The stlinkv3 was recently added to blackmagic probe fingers crossed they work on fixing its usb2uart. So I received my hydrausb boards yesterday and today I find this post. Guess maybe I could spend sum more time on usb 2 cdc on faster interfaces for a bit. I assume I can find an english reference manual/datasheet on one of these repos. I'm curious what interrupts ill have to use, something akin to uart's idle and dma's tx complete would be ideal. I've never had anything with usb3 I could play with so ill hafta read that spec as well. USB2HS had the "strict" 512 bulk endpoints packet size I assume usb3 will have even higher, and I guess if they changed what the binterval represents for a time measurement again ill need to know, maybe just those 2 things will hopefully be enuff to get me on my feet. If you forsee any curve balls I might be overlooking pls let me know. Have you started any work on this that is/or can be posted somewhere? Great work, great product, As always I appreciate your contributions to the opensource hardware/software scene. hrm just realized usb3 was closed blob driver so doubtfull all its registers are in official docs, I assume you must have documented your code etc and also maybe all the registers? and all possible options for them? Ha I'm not asking for much huh? Alright I'm off to get docs

I'm not working on that so you are free to work on it and such type or contribution is very welcome.

The USB3 blob has been reversed and available with clean C code here (for USB2 & USB3 Device Bulk only today) https://github.com/hydrausb3/wch-ch56x-bsp/tree/main/usb/usb_devbulk

  • It could be cleaned to be more generic to be defined supporting Interrupt, isochronous ...
    • Other idea is to have an USB2 / USB3 stack a bit like TeenyUSB see below for more details

For more details on different registers for USB2 see following documents:

For more details on different registers for USB3 (it is very basic) see https://github.com/hydrausb3/wch-ch56x-bsp/blob/main/drv/CH56xSFR.h#L1652 and check different examples how are used those registers

About documentation WCH does not provide anything for USB3 and everything shall be checked in https://github.com/hydrausb3/wch-ch56x-bsp/tree/main/usb/usb_devbulk (even if it support only device bulk so far contribution are welcome to add interrupt and isochronous modes) see example usage of that library for USB2 HS & USB3 SS here https://github.com/hydrausb3/hydrausb3_fw/tree/main/HydraUSB3_USB

Of course I recommend you to also check WCH CH569 official example https://github.com/openwch/ch569 even if they do not have provided any USB CDC example with USB3.

An other interesting point (mainly for test and learning purpose) is to check https://github.com/xtoolbox/TeenyUSB which is a higher level USB stack support "basically" WCH CH569 USB2 HS & USB3 SS even if there is some bugs / not finished and is like abandon-ware since lot of time

  • Their code need some fixes anyway in TeenyUSB/driver_ch56x/CH56xUSB30_LIB.h
static inline void USB30_IN_Set(UINT8 endp,FunctionalState lpf,UINT8 status,UINT8 nump,UINT16 TxLen)
{
    UINT32V* p = &USBSS->UEP0_TX_CTRL;
    p+= endp*4;
    *p = *p | (nump<<16) | (status<<26) | (TxLen & 0x7ff) | (lpf << 28);
}
static inline void USB30_OUT_ClearIT(UINT8 endp)
{
    UINT32V* p = &USBSS->UEP0_RX_CTRL;
    p+= endp*4;
    *p &= 0x03e00000;
}

TeenyUSB/sample/boards/ch565w_evk/board.c

  • Change #define FREQ_SYS 80000000 by #define FREQ_SYS 120000000

Long time ago I have tested only TeenyUSB/sample/winusb30 with HydraUSB3 which works

It will be nice to cleanup that TeenyUSB stack and use https://github.com/hydrausb3/wch-ch56x-bsp (instead of TeenyUSB/tree/master/driver_ch56x/ch56xlib which is buggy see my previous comment about openwch/ch569/blob/main/EVT/EXAM/SRC/* issues) and of course cleanup all the TeenyUSB/driver_ch56x/CH56xUSB30_LIB.h to have something like https://github.com/hydrausb3/wch-ch56x-bsp/usb/teenyusb ... to have something reusable for everyone...

Other interesting usb stack will be to do port of WCH CH569 USB2 & USB3 for https://github.com/hathach/tinyusb which is clearly better(with active developer / active community)

@bm16ton
Copy link

bm16ton commented Jun 15, 2023

Oh wow thank you for responding! Yes I found most of those as well and had "ported" the official example over to your lib etc. Makes me feel better knowing I was already going in the same way you suggested, as Im still fairly green at a lot of this. I haven't had much time after gathering materials and basically added the usb descriptors and it enumerates as usb-cdc with 1 interrupt and 2 bulk endpoints in union. I was figuring it would be quick and easy to have log buff printed over the interface, and it does, but so doesn't a lot of gibberish. Im hoping to find more time to dedicate maybe next week. Currently don't have a usb3 type A to type A will hafta get on that. Making the usb stuff more generic, any particular way you would prefer to see that go? Like have the isr do the basic/needed stuff then call a weakly defined function that the user can use as his/her isr in project? The teenyusb stack does look like its no longer supporting the ch56X, So i guess if I was to base the stack on anything I would probly base it off libopencm3, which i have found to be the easiest to use USB stack. Altho not much to see it may save someone the time of writing the usb descriptors, so heres my code. https://github.com/bm16ton/ch569-cobled-sdk It doesn't look like the ch569 has that many peripherals compared to the stm32h7 so possibly an easier port then that was. Ill check it out and may go that way. I read somewhere the ch569 shares at least something with ch32v103 and that would make those parts much easier for sure. Anyway I got long winded thank you again for responding and all your awesome work, Wish I could find the audio of your presentation on reverse engineering the blobs not just the pdf/slides, such an amazing thing, and parts so far above my head :)

@bvernoux
Copy link
Member Author

bvernoux commented Jun 15, 2023

Thanks for the feedback it will be perfect to just have an example which have a working USB-CDC for USB2 HS & USB3 SS working fine basic Device stack supporting automatic plug&play driver installation(WinUSB) for Windows8 or more.
I'm watching your progress on https://github.com/bm16ton/ch569-cobled-sdk

Then why not doing something easier to use a bit like an USB stack and why not after to go further doing the port of WCH CH56x USB2 LS/FS/HS & USB3 SS to https://github.com/hathach/tinyusb (as so far the Author has no time to work on that)

@bm16ton
Copy link

bm16ton commented Jun 15, 2023

I did a couple of ports a while ago to tinyusb, It didnt have interrupt endpoints at the time, i think it was interrupts maybe iso its been so long, between that and the cube/hal libs it required (was mostly using stm32 at the time) lead me away, but I also had the same thought of revisiting. Lots of people like that lib so it would be good for a broader range of people. I wont take up any more of your time for now, and will plug away with not only usb stuff but maybe general sdk like stuff as well. The potential to sniff usbhs with the dancer firmware is to exciting not to take a crack at as well. Very cool stuff. I hope and pray someday I get to design cool boards/tech like this.

@bm16ton
Copy link

bm16ton commented Jun 23, 2023

So a couple of questions, which I am sorry for. After I added cdc descriptors to both 2/3 usb2 immediatly starts receiving debug msgs and gibberish(which I believe sum are a different baudrate). Are you aware of which/where function is providing this? I commented out the _writes removed the init for the log and still it gets it. Usb3 has been much more difficult, for usb in (pc in) I keep thinking I understand it and failing, a simple list of order of operations so a simple send/rec functions could be written would be unbelievably helpfull. I see sum magic numbers around and hopefully will figure those out. I've never dealt with USB3 mcu side before, looks like its all dma based with no registers for simple send and receive (makes sense to much for the cpu to handle at those speeds I'm guessing). The tx done function asks for a buffer (going from memory hope that's write) just curious, tx done suggests its called after all tx is done so is the buffer the receive buffer to be set? I've been trying to combine your code with the Teenyusb code, but even using the sdk to compile it with the simple changes required (mostly capitol letters etc) and with or without your patches I cannot get it to enumerate (times out). But simply using your usb callback gets it to enumerate so ill start with that. In the end interrupt endpoint and simple send/rec functions would make me happy and maybe give others an easier starting place. As for basic "pc usb send" "mcu receive" it was simply adding a uart send command in enpoint 1s callback so I think I can work from that easily enuff. But I'm very curious why simply adding cdc descriptors for the interfaces/endpoints without any of the additional cdc specific ones makes debug data be sent to it. With my adapter connected to uart2 and everything set in software to uart1 I still get loopback but at a ddifferent baudrate on uart2..why? If I send 3 charactors I receive 3 gibberish charactoes (same for any amount of charactors) I grepped and removed all uart2 related code I could find and it still happens. Once I find a usb3-c to A adapter(and $ to get it lol) I can use wireshark, but going thru a hub is a pain. And my last question its stated in your paperwork using swd for programming or debugging can possibly brick the board, that could surely bennefit from a explanation. The programming part I get, I assume the bootloader isn't hard baked and can be overwritten and possibly that or another rw section is required for future programming and can be over written. Is the debug issue a readback protection/or otp fuse thing? Cuz id love to hook a debugger up. using usb/uart for debugging when usb/uart is what your working on has proven difficult. So sorry to take up more of your time and unbelievably greatful for your previous responses. If your to busy to respond tbis time I totally get it. Thank you again! the little time I've spent on it so far has been very enjoyable and fun.

@bvernoux
Copy link
Member Author

The best is maybe to discuss about that on a dedicated channel (development / firmware for example) on HydraUSB3 Discord (https://discord.gg/6DCVURV5c2)

@bm16ton
Copy link

bm16ton commented Jun 24, 2023

Ha yeah I can see now that was a bunch of foolish questions in a row. I do know better then to bother my betters, I just get excited a forget sometimes. I do apologize. It takes me longer then most but eventually I always seem to get it done. ill send a PR if this ends up being the case. Thank you good sir!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants