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

drivers/usbdev_synopsys_dwc2: add GD32V support #19389

Merged
merged 24 commits into from
Apr 17, 2023

Conversation

gschorcht
Copy link
Contributor

@gschorcht gschorcht commented Mar 14, 2023

Contribution description

This PR provides the GD32V support in drivers/usbdev_synopsys_dwc2. It also includes some cleanup and bug fixes.

To support GD32V (CID 1.000) the PR includes the following changes:

  • XFRC interrupts are also used in Non-DMA mode to complete a transfer
  • SETUP phase done (STUP) interrupt is used in Non-DMA mode
  • additional XFRC interrupts in SETUP stage are ignored
  • RX FIFO handling doesn't complete a transfer anymore and is handled directly in ISR
  • OTG interrupt handling added

The following fixes, improvements and cleanup has been added:

  • USB OTG HS definition dependencies for platforms that don't support USB OTG HS
  • thread context switch at ISR exit was added for all platforms
  • units in USB FIFO size definitions are clarified
  • USB EP number as defined in CMSIS is used
  • FIFO allocation documentation is improved
  • power modes for STM32 are fixed
  • CID/HW debug info added

The PR could be split into a PRs with cleanups and improvements and a PR with GD32V support if necessary.

Testing procedure

BOARD=sipeed-longan-nano make -j8 -C tests/shell

should work with stdio_cdc_acm.

periph_usbdev should still work for other platforms. The PR was tested with tests/usbus_cdc_ecm together with stdio_cdc_acm if possible:

esp32s2      FS  CID: 0000, HWREV: 4f54400a, HWCFG: 224dd930  (esp32s2-devkit)
esp32s3      FS  CID: 0000, HWREV: 4f54400a, HWCFG: 224dd930  (esp32s3-devkit)
efm32gg12    FS  CID: 0000, HWREV: 4f54330a, HWCFG: 228f5910  (sltb009a)
gd32vf103cb  FS  CID: 1000, HWREV: 00000000, HWCFG: 00000000  (sipeed-longan-nano)
stm32f407vg  FS  CID: 1200, HWREV: 4f54281a, HWCFG: 229dcd20  (stm32f4discovery) 
stm32f429zi  HS  CID: 1100, HWREV: 4f54281a, HWCFG: 229ed590  (stm32f429i-disc1)
stm32f439zi  FS  CID: 1200, HWREV: 4f54281a, HWCFG: 229dcd20  (nucleo-f439ze)
stm32f446ze  FS  CID: 2000, HWREV: 4f54320a, HWCFG: 229ed520  (nucleo-f446ze)
stm32f723ie  FS  CID: 3000, HWREV: 4f54330a, HWCFG: 229ed520  (stm32f723e-disco)
stm32f723ie  HS  CID: 3100, HWREV: 4f54330a, HWCFG: 229fe1d0  (stm32f723e-disco)
stm32f746ng  FS  CID: 2000, HWREV: 4f54320a, HWCFG: 229ed520  (stm32f746g-disco)
stm32f746ng  HS  CID: 2100, HWREV: 4f54320a, HWCFG: 229fe190  (stm32f746g-disco)
stm32f767zi  FS  CID: 2000, HWREV: 4f54320a, HWCFG: 229ed520  (nucleo-f767zi)

Boards with HS interfaces were tested in DMA and none-DMA mode.

Issues/PRs references

@github-actions github-actions bot added Area: boards Area: Board ports Area: cpu Area: CPU/MCU ports Area: drivers Area: Device drivers Area: Kconfig Area: Kconfig integration Platform: ARM Platform: This PR/issue effects ARM-based platforms Platform: ESP Platform: This PR/issue effects ESP-based platforms labels Mar 14, 2023
@gschorcht gschorcht requested a review from bergzand March 14, 2023 17:45
@benpicco benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Mar 15, 2023
@riot-ci
Copy link

riot-ci commented Mar 15, 2023

Murdock results

✔️ PASSED

1e983f3 boards/common/gd32v: enable usb_board_reset if USB CDC ACM is used

Success Failures Total Runtime
6882 0 6882 09m:08s

Artifacts

@github-actions github-actions bot added the Area: tests Area: tests and testing framework label Mar 15, 2023
Copy link
Contributor

@benpicco benpicco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works like a charm and I see you already have tested this on a wide range of implementations.

Please squash.

drivers/usbdev_synopsys_dwc2/usbdev_synopsys_dwc2.c Outdated Show resolved Hide resolved
drivers/usbdev_synopsys_dwc2/usbdev_synopsys_dwc2.c Outdated Show resolved Hide resolved
@gschorcht
Copy link
Contributor Author

Works like a charm and I see you already have tested this on a wide range of implementations.

I would like to have look from @bergzand onto the driver since its interrupt handling has been changed completely (commits bcc8c2b, 38620fd, ad191b1)

@gschorcht gschorcht added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Type: new feature The issue requests / The PR implemements a new feature for RIOT labels Mar 16, 2023
@bergzand
Copy link
Member

I would like to have look from @bergzand onto the driver since its interrupt handling has been changed completely (commits bcc8c2b, 38620fd, ad191b1)

I see one potential race condition here, but not sure if it is the case. For the non-DMA case both the rxfifolvl and the transfer complete interrupts are enabled. I previously had a similar issue with the DMA case where both the transfer complete and the rxfifolvl interrupts were enabled (see #18726). On fast microcontrollers with HS phy this could trigger unstable behaviour quickly when using cdc ecm and pinging the device with large icmp packets. I wonder if this issue returns here but for the non-dma case, with a HS phy.

I'm also curious why a different interrupt is used during the address state.

@gschorcht
Copy link
Contributor Author

gschorcht commented Mar 16, 2023

I see one potential race condition here, but not sure if it is the case. For the non-DMA case both the rxfifolvl and the transfer complete interrupts are enabled.

The causal order should be that RXFLVL comes before XFRC. There shouldn't be a race condition because only one interrupt is handled per ISR call and RXFLVL is always handled before XFRC even if RXFLVL and XFRC are triggered at the same time. In addition, RXFLVL is handled synchronously directly in the ISR while XFRC is handled asynchronously using thread events. Also, RXFLVL is only used to copy the FIFO contents and to set a flag indicating that a SETUP transfer has been started. The latter is seems to be needed for certain core versions such as the GD32V core version 1.000.

I'm also curious why a different interrupt is used during the address state.

Because TXFE interrupt doesn't seem to work in default state in core version 1.000 😟

* while (un)blocking works on the stm32f401, needs more
* investigation with a larger set of chips */
#if defined(STM32_USB_OTG_CID_1x)
#if defined(MCU_STM32)
Copy link
Contributor Author

@gschorcht gschorcht Mar 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bergzand I am not sure if this change could cause it to stop working on the stm32f446. I have tested it with a number of non CID 1.x core versions but could not find a problem.

@gschorcht
Copy link
Contributor Author

I had to rebase to resolve the conflicts.

@github-actions github-actions bot removed Area: USB Area: Universal Serial Bus Area: sys Area: System labels Apr 16, 2023
@gschorcht
Copy link
Contributor Author

Please rebase now that #19471 is merged

Thanks for merging PR #19471. I rebased the PR and squashed the small change with static assert right away.

XFRC (Transfer Complete) interrupts are now also used for OUT EPs in non-DMA mode. RXFLVL (RX FIFO Level) interrupts are no longer used to signal completed transfers, but only to copy data from FIFO to memory and to set a flag indicating that a SETUP stage is in progress. STUP (SETUP phase done) interrupts are then used to signal a completed SETUP stage and to reset the flags that indicates the SETUP stage. The flag that indicates the SETUP stage in progress is used to ignore additional XFRC interrupts for EP0 during the SETUP stage.
Since RXFLVL (RX FIFO Level) interrupt doen't complete transfers anymore, they are handled now directly in the ISR.
After changing IN EPs also to use XFRC (Transfer Complete) interrupts in non-DMA mode, the TXFE (TX FIFO Empty) interrupt is no longer needed to signal the completion of an IN transfer.
bors bot added a commit that referenced this pull request Apr 16, 2023
@bors
Copy link
Contributor

bors bot commented Apr 16, 2023

try

Build succeeded:

Copy link
Member

@bergzand bergzand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack, thanks for the many improvements!

bors merge

@bors
Copy link
Contributor

bors bot commented Apr 17, 2023

Build succeeded:

@bors bors bot merged commit 82234b1 into RIOT-OS:master Apr 17, 2023
@gschorcht
Copy link
Contributor Author

Thanks for reviewing, testing und merging.

@gschorcht gschorcht deleted the cpu/gd32v/periph_usbdev branch April 26, 2023 09:39
@benpicco benpicco added this to the Release 2023.07 milestone Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: boards Area: Board ports Area: cpu Area: CPU/MCU ports Area: drivers Area: Device drivers Area: Kconfig Area: Kconfig integration Area: tests Area: tests and testing framework CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Platform: ARM Platform: This PR/issue effects ARM-based platforms Platform: ESP Platform: This PR/issue effects ESP-based platforms Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants